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
The option --leak-check-heuristics=heur1,heur2,... can activate
various heuristics to decrease the number of false positive
"possible leaks" for C++ code. The available heuristics are
detecting valid interior pointers to std::stdstring, to new[] allocated
arrays with elements having destructors and to interior pointers pointing
to an inner part of a C++ object using multiple inheritance.
This fixes 280271 Valgrind reports possible memory leaks on still-reachable
std::string
This has been tested on x86/amd64/ppc32/ppc64.
First performance measurements seems to show a neglectible impact on
the leak search.
More feedback welcome both on performance and functional aspects
(false positive 'possibly leaked' rate decrease and/or
false negative 'possibly leaked' rate increase).
Note that the heuristic is not checking that the memory has been
allocated with "new" or "new[]", as it is expected that in some cases,
specific alloc fn are used for c++ objects instead of the standard new/new[].
If needed, we might add an option to check the alloc functions
to be new/new[].
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13582
it turned out that coregrind freely allocates memory on the tool
arena (which it should not, conceptually) and tools rely on coregrind
doing so (by VG_(free)'ing memory allocated by coregrind).
Entangling this mess is risky and provides little benefit except
architectural cleanliness.
Thinking more about it... It isn't really all that interesting how
much memory is allocated by tool code in and by itself. What is
interesting is the total memory impact a tool has, e.g. as compared
to running "none".
So in this patch the number of memory arenas is consolidated by
subsuming VG_AR_TOOL/ERRORS/EXECCTXT into VG_AR_CORE.
VG_(malloc) and friends have been modified to operate on VG_AR_CORE.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13575
are not against the grain.
Wrap this script together with 'check_makefile_consistency' into
'post_regtest_checks' and invoke that from the toplevel Makefile. So we can
easily add new checkers in the future.
Add a new make target 'post-regtest-checks' to just run those checks
and nothing else.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13570
non-phone/tablet targets. The previous apparently-huge sizing is
evidently not huge enough for recent apps, eg, recent Firefox requires
circa 350k translations to get started and almost fills an 8-sector
cache merely starting up and then idling.
On Android targets, fall back to 6 sectors; space is critical.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@13568
