in VEX r2727 (conversion ops between binary floating point and
decimal floating point).
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Part of fixing BZ 307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13428
the definedness check and possible shadow temp set-to-defined be
optional. Use this to properly instrument IRLoadG and IRStoreG, so
that if the load/store does not happen, not only is the validity of
the address not checked, neither is the definedness.
This fixes a regression introduced by the COMEM branch on ARM, in
which conditional loads/stores with addresses which are undefined at
runtime and with guards which are false, would generate false errors.
Also extensively re-checked the check-generation machinery and updated
a bunch of comments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13386
The implementation of integer operands doesn't really match the documentation
for the Iop. Take for example Iop_ExtractExpD64. It is documented as
D64 -> I64 but the implementation of the UNARY is defined as
UNARY(Ity_D64, Ity_D64). The result is an integer that is stored in an integer
format in a floating point register. On the IBM s390 however, the architecture
stores the integer value in a general purpose register (GPR) not a floating
point register. This issue exists with the implementation of 11 Iops where the
PPC implementation has either a source or destination whose value is an integer
but the value is stored in a floating point register in an integer format. After
reviewing the PPC implementation with the s390 developer, it was agreed the
cleanest way to fix this is to change the PPC implementation. The BINOP will be
changed to be consistent with the Iop description. This means the PPC
instruction implementation of the PPC instruction in guest_ppc_toIR.c will need
to reinterpret integer source operands as integers which will move the value
from a floating point register to an integer register before calling binop().
The underlying PPC implementation of the unop() for the specific Iop will also
need to change to move the value from the integer register back to the floating
point register so the native instruction can be issued with the integer value
in a floating point register. It was decided that making the changed in PPC,
rather then having the s390 reinterpret integers as DFP and then move the value
back to an integer register, was preferable as it makes the implementation of
the unop(), binops(), triop() consistent with the definition of the Iop.
This patch also includes the needed changes for the vbit tester. The Iop
definitions in memcheck/tests/vbit-test/util.c had to be updated to be consitent
with the changes in the Iops as documented below. Also, the function mkLazy3()
in memcheck/mc_translate.c had to be updated to handle the I32 x I8 x I64 -> I64
and I32 x I8 x I128 -> I128 cases.
The specific list of changes are as follows:
Iop name in pub/libvex_ir.h
documented type
type of UNARY/BINARY/TERNARY in priv/ir_defs.c
-------------------------------------------------------
Iop_ExtractExpD64
D64 -> I64
UNARY(Ity_D64, Ity_D64); (current)
UNARY(Ity_D64, Ity_I64); (fix)
Iop_ExtractExpD128
D128 -> I64
UNARY(Ity_D128, Ity_D64); (current)
UNARY(Ity_D128, Ity_I64); (fix)
Iop_InsertExpD64
I64 x I64 -> D64
I64 x D64 -> D64 (fix definition)
BINARY(Ity_D64,Ity_D64, Ity_D64); (current)
BINARY(Ity_I64,Ity_D64, Ity_D64); (fix)
Iop_InsertExpD128
I64 x I128 -> D128
I64 x D128 -> D128 (fix definition)
BINARY(Ity_D64,Ity_D128, Ity_D128); (current)
BINARY(Ity_I64,Ity_D128, Ity_D128); (fix)
Iop_I64StoD128
I64S -> D128
UNARY(Ity_D64, Ity_D128); (current)
UNARY(Ity_I64, Ity_D128); (fix)
Iop_D64toI64S
IRRoundingModeDFP(I32) x D64 -> I64
BINARY(ity_RMode, Ity_D64, Ity_D64) (current)
BINARY(ity_RMode, Ity_D64, Ity_I64) (fix)
Iop_D128toI64S
IRRoundingModeDFP(I32) x D128 -> I64
BINARY(ity_RMode, Ity_D128, Ity_D64); (current)
BINARY(ity_RMode, Ity_D128, Ity_I64); (fix)
Iop_I64StoD64
IRRoundingModeDFP(I32) x I64 -> D64
BINARY(ity_RMode, Ity_D64, Ity_D64); (current)
BINARY(ity_RMode, Ity_I64, Ity_D64); (fix)
Iop_SignificanceRoundD64
IRRoundingModeDFP(I32) x I8 x D64 -> D64
TERNARY(ity_RMode,Ity_D64,Ity_D64, Ity_D64); (current)
TERNARY(ity_RMode,Ity_I8,Ity_D64, Ity_D64); (fix)
Iop_SignificanceRoundD128
IRRoundingModeDFP(I32) x I8 x D128 -> D128
TERNARY(ity_RMode,Ity_D128,Ity_D128, Ity_D128); (current)
TERNARY(ity_RMode,Ity_I8,Ity_D128, Ity_D128); (fix)
The patch is for bugzilla 311100
VEX Committed revision 2652
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13260
functions to indicate a "true" expression. That caused some confusion
and led people to believe believe, that IRDirty::guard could be NULL.
It cannot.
This confusion was indirectly spotted by coverity's checker who figured
out that IRDirty::guard was sometimes unconditionally dereferenced
and sometimes compared against NULL.
Cleaning this up...
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13250
Adapt vbit-tester.
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
Part of fixing BZ 307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13224
VEX buddy patch is r2617.
Enhance testcase for CEDTR and CEXTR. Adapt vbit tester.
Patch by Maran Pakkirisamy (maranp@linux.vnet.ibm.com).
This is part of fixing BZ 307113.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13203
with the required IRDefault (guarded-dirty-call default return result
specifications).
git-svn-id: svn://svn.valgrind.org/valgrind/branches/COMEM@13187
addresses in guarded loads, stores and dirty helpers that access
memory. Fall back to a simpler situation as documented in the
comment, possibly on a temporary basis.
git-svn-id: svn://svn.valgrind.org/valgrind/branches/COMEM@13181
Still to do:
* origin tracking
* reinstate the two NULLed-out 3rd args to complainIfUndefined,
once the complication pertaining to setting the shadow tmp to
'defined' is resolved
git-svn-id: svn://svn.valgrind.org/valgrind/branches/COMEM@13142
BSF instructions, as the lack of it causes false positives (Valgrind
side). Fixes#308627. (Patrick J. LoPresti <lopresti@gmail.com>)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13108
Testcase, vbit tester update, memcheck support for the new IROps,
NEWS announcement and opcode list update.
Patch by Christian Borntraeger (borntraeger@de.ibm.com).
Vbit tester tweaks by myself.
Fixes bugzilla #274695.
See also companion patch VEX r2496.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12921
Iop_Mul8, Iop_Sar8, Iop_CmpwNEZ32, and Iop_8HLto16.
With this change mc_translate now handles all IR ops which are architecture
independent, except Iop_LeftXYZ and Iop_Max32U.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12884
This means, that any guest state and/or memory accesses of the helper (and
complaints about those) only occur if the guard expression is true at runtime.
Definedness of parameters that the helper might have is *always* checked,
as parameters are evaluated regardless of the guard expression.
New functions: expr2vbits_guarded_Load and gen_guarded_load_b.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12762
(Carl Love, carll@us.ibm.com and Maynard Johnson, maynardj@us.ibm.com)
This patch adds support for Power Decimal Floating Point (DFP) . This
is the fifth patch set in the series of five to add the DFP
instruction support to Valgrind. Adds support for the ddedpd,
ddedpdq, denbcd, denbcdq, dtstsf, and dtstsfq instructions.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12603
by allocating the details of a PutI statement into a struct
of its own and link to that (as is being done for Dirty and CAS).
These are the valgrind bits (see also VEX r2361).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12596
test group and test exponent instructions dtstdc, dtstdcq, dtstdg,
dtstdgq, dtstex and dtstexq. Bug #298862. (Carl Love,
carll@us.ibm.com and Maynard Johnson, maynardj@us.ibm.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12546
instruction support -- VEX side changes. See #295221.
This patch adds test cases. Also adds some minor Memcheck
instrumentation tweaks necessitated by the IR changes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@12476
