Change the input values so that the binary values
is representing exactly the same float values.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13632
* initialise leak_check heuristic parameter in the leak_check monitor command
* show the default value (none heuristic) in the monitor help command
(none value chosen as default as this gives a backward compatible
behaviour).
* document the heuristic leak check parameter in memcheck manual
monitor command section
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13631
The initial Transactional Memory instruction patch did not include the two
privileged (OS) instructions treclaim and trechkpt. VEX commit 2784 added
the support for these two instructions.
This patch adds a touch test to make sure all of the POWER Transactional
memory instrutions are recognized by Valgrind. All of the the Transactional
Memory instructions, with the exception of tbegin, are treated as NOPs in the
first implementation. The tbegin instruction causes the transaction to fail
thus no additional Transactional Memory instructions on the successful
transaction path would be executed in a real program. This test just makes
sure each instruction is actually recognized by Valgrind.
The patch if for Bugzilla 325751.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13630
The fault catcher installed during leak scan to catter e.g. for
possible desynchronisation between real protection and aspacemgr
was not activated when the scanned ptr was directly pointing in
a desynchronised page.
This was (initially only) visible on ppc32 (gcc110) as the page size of
gcc110 is big (64 K).
=> modified the leak-segv-jmp test so as to produce the problem also
on systems with smaller pages.
The fix consists in calling the setjmp before the scan loop,
and skip the bad address which has been recorded by the fault
catcher.
Also, deemed better to just skip one single Addr rather than a full page
(e.g. to skip less data in case some addresses are unreadable e.g.
on strange hardware).
Performance of the leak scan has been measured, seems slightly
faster on x86,amd64 and ppc32. Slightly slower on ppc64.
Also if verbose argument is given, outputs the nr of bytes skipped
due to fault.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13623
* Remove dead code in m_oset.c VG_(OSetGen_ResetIterAt)
The code at the end of VG_(OSetGen_ResetIterAt) was unreachable
(detected by BEAM checker).
Looking at SVN, the initial commit of VG_(OSetGen_ResetIterAt)
already contained this deadcode.
* pub_tool_oset.h was wrongly indicating that signed words could
be used for fast cmp oset.
* modified memcheck/tests/unit_oset.c to test VG_(OSetGen_ResetIterAt)
* modified memcheck/tests/unit_oset.c to not use signed words
(it was previously using signed words, but only with positive values)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13622
clang 3.3 produces an error message for /usr/include/c++/4.6/chrono
which happens to get included somewhere inside <thread>.
This happens with C++ headers from:
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13620
setting suppresses almost all warnings originating in source code
constructs. It does ot yet suppress warnings from unrecognised command
line flags as they may be the reason for regression test failures
which have not yet been investigated.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13619
Those tests were rejected by clang and according to the
analysis below by Tom Hughes do not add anything new.
Analysis:
I'm not 100% sure that clang is right though - the Intel manual
clearly describes that argument as "reg" rather than "r32" which
is why I will have included the 64 bit version in the test. It also says:
"The upper bits of r32 or r64 is zeroed."
and:
"If the destination operand is a general-purpose register, the
default operand size is 64-bits in 64-bit mode."
which basically means that REX.W is implied for this op and there is
no way to encode a 32 bit version when running in 64 bit mode.
So in principle you could encode it as:
44 0f c5 ce 00 pextrw $0x0,%mm6,%r9d
or:
4c 0f c5 ce 00 pextrw $0x0,%mm6,%r9
but in fact gcc assembles both versions to the first form.
Equally you could argue that as REX.W is implied both versions
should disassemble as %r9.
So I think clang is being overly picky, and if it was only going to
accept one version I would argue it should be %r9 not %r9d!
In practical terms dropping the second set of tests doesn't lose us anything though.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13614
With the change, the test compiles on ppc32.
However, the test fails miserably with
Segmentation fault
while the whole purpose of the test was to see the leak search
would *not* segfault.
More investigations needed, but still committing as is to let
the tests compile and run.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13612
This patch adds testcases for the following instructions added
in phase 4. The instructions are for doing various arithmetic,
logic, and load/store VSX operations:
xscvsxdsp xscvuxdsp xsaddsp xssubsp xsdivsp xsmaddasp xsmaddmsp
xsmsubasp xsmsubmsp xsnmaddasp xsnmaddmsp xsnmsubasp xsnmsubmsp
xsmulsp xssqrtsp xsresp xsrsqrtesp xsrsp xxlorc xxlnand xxleqv
lxsiwzx lxsiwax lxsspx stxsiwx stxsspx
Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
VEX commit for the instruction support r2781
Bugzilla 325477
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13611
as suggested by John Reiser and Greg Parker.
It seems that GCC has a more relaxed attitude about what it accepts
as valid input.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13610
* fix the assert
* some better comments
* update test to verify who_points_at behaviour with an interiorly pointed block
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13609
compilers as the -mhtm flag is not known. The patch fixes the makefile
issue and addes #defines to the testcase code.
The testcase was added in valgrind commit 13607.
The bugzilla for adding the TM instruction support is 323803
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13608
The test case for the transaction memory instructions executes the
failure path when run under valgrind. This is since the initial
Transaction Memory implemnetation is to simply fail the TBEGIN instruction
forcing the execution flow to take the failure path. When the
test case is executed on the real hardware, the success path will
be taken. Only the TBEGIN instruction actually does anything. All other
transactional memory instructions are NOPs since only failure path is executed
and it assumed to not have any transactional memory instructions on it.
Signed-off-by: Carl Love <cel@us.ibm.com>
VEX commit revision 2780
Bugzilla 323803
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13607
Non-POD variable length arrays are supported by g++ but not by clang.
Hence convert the variable length array in this test program into a vector.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13606
were mixing up CFLAGS and CXXFLAGS. Now fixed.
Also, when modifying CFLAGS also modify CXXFLAGS unless there is a
good reason not to do so. This only affects compilation of testcases.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13604
Also allow a .git directory in check_headers_and_includes to help
people using a git mirror of valgrind/VEX svn.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13601
This patch adds testcases to an existing testcase
source file to test the new instructions which were
added to VEX support in the phase 3 ISA 2.07 code patch.
The patch also makes a small change to memcheck's
vbit tester code to allow successful execution.
Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
Bugzilla 324894. Corresponding VEX commit 2779
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13594
Valgrind is doing mmap always with MAP_FIXED. On mips32 we need to check arg4.
If the arg4 is MAP_SHARED we need to align the address to SHMLBA.
If the program tries to do mmap with VKI_FIXED Valgrind doesn't need to align
the address to SHMLBA.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13593
Depending on the compiler or optimisation level, the blocks that
are supposed to be possibly leaked are still reachable.
=> change the pointers to be global variables,
and do the allocation in a function, not in main.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13591
