Version: 3.6 SVN (using KDE 4.3.5) OS: Linux $ uname -m ppc64 $ svn info . | grep Revision Revision: 11207 $ ./vg-in-place -v -d --tool=callgrind --cache-sim=yes --branch-sim=yes callgrind/tests/simwork --20664:1:debuglog DebugLog system started by Stage 1, level 1 logging requested --20664:1:launcher tool 'callgrind' requested --20664:1:launcher selected platform 'ppc64-linux' --20664:1:launcher launching /home/bart/software/valgrind/nightly/valgrind-new/./.in_place/callgrind-ppc64-linux --20664:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging requested --20664:1:main Welcome to Valgrind version 3.6.0.SVN debug logging --20664:1:main Checking current stack is plausible --20664:1:main Checking initial stack was noted --20664:1:main Starting the address space manager --20664:1:main Address space manager is running --20664:1:main Starting the dynamic memory manager --20664:1:mallocfr newSuperblock at 0x402010000 (pszB 4194272) owner VALGRIND/tool --20664:1:main Dynamic memory manager is running --20664:1:main Initialise m_debuginfo --20664:1:main VG_(libdir) = /home/bart/software/valgrind/nightly/valgrind-new/./.in_place --20664:1:main Getting launcher's name ... --20664:1:main ... /net/home/bart/software/valgrind/nightly/valgrind-new/coregrind/valgrind --20664:1:main Get hardware capabilities ... --20664:1:machine F 1 V 1 FX 1 GX 1 --20664:1:main ... arch = PPC64, hwcaps = ppc64-int-flt-vmx-FX-GX --20664:1:main Getting the working directory at startup --20664:1:main ... /net/home/bart/software/valgrind/nightly/valgrind-new --20664:1:main Split up command line --20664:1:main (early_) Process Valgrind's command line options --20664:1:main Create initial image --20664:1:initimg Loading client --20664:1:initimg Setup client env --20664:1:initimg Setup client stack: size will be 10485760 --20664:1:initimg Setup client data (brk) segment --20664:1:main Setup file descriptors --20664:1:main Create fake /proc/<pid>/cmdline --20664:1:main Initialise the tool part 1 (pre_clo_init) --20664:1:main Print help and quit, if requested --20664:1:main (main_) Process Valgrind's command line options, setup logging --20664:1:main Print the preamble... ==20664== Callgrind, a call-graph generating cache profiler ==20664== Copyright (C) 2002-2010, and GNU GPL'd, by Josef Weidendorfer et al. ==20664== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info ==20664== Command: callgrind/tests/simwork ==20664== --20664-- Valgrind options: --20664-- -v --20664-- -d --20664-- --tool=callgrind --20664-- --cache-sim=yes --20664-- --branch-sim=yes --20664-- Contents of /proc/version: --20664-- Linux version 2.6.25.14-108.20080910bsc.ppc64 (root@localhost.localdomain) (gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) ) #1 SMP Fri Sep 12 11:44:36 CEST 2008 --20664-- Arch and hwcaps: PPC64, ppc64-int-flt-vmx-FX-GX --20664-- Page sizes: currently 65536, max supported 65536 --20664-- Valgrind library directory: /home/bart/software/valgrind/nightly/valgrind-new/./.in_place --20664:1:main ...finished the preamble --20664:1:main Initialise the tool part 2 (post_clo_init) --20664-- Warning: Cannot auto-detect cache config on PPC64, using one or more defaults ==20664== Cache configuration used: ==20664== I1: 65536B, 2-way, 64B lines ==20664== D1: 65536B, 2-way, 64B lines ==20664== L2: 262144B, 8-way, 64B lines ==20664== For interactive control, run 'callgrind_control -h'. --20664:1:main Initialise TT/TC --20664:1:main Initialise redirects --20664:1:mallocfr newSuperblock at 0x402490000 (pszB 1048544) owner VALGRIND/dinfo --20664:1:main Load initial debug info --20664-- Reading syms from /net/home/bart/software/valgrind/nightly/valgrind-new/callgrind/tests/simwork (0x10000000) --20664-- Reading syms from /net/home/bart/software/valgrind/nightly/valgrind-new/callgrind/callgrind-ppc64-linux (0x38000000) --20664:1:mallocfr newSuperblock at 0x402590000 (pszB 1048544) owner VALGRIND/dinfo --20664-- object doesn't have a dynamic symbol table --20664:1:mallocfr newSuperblock at 0x402690000 (pszB 1048544) owner VALGRIND/dinfo --20664:1:mallocfr newSuperblock at 0x402790000 (pszB 2097120) owner VALGRIND/dinfo --20664:1:mallocfr newSuperblock at 0x402990000 (pszB 4128736) owner VALGRIND/dinfo --20664-- Reading syms from /lib64/ld-2.8.so (0x8094d30000) --20664:1:redir transfer ownership V -> C of 0x38030000 .. 0x3803ffff --20664:1:main Initialise scheduler (phase 1) --20664:1:sched sched_init_phase1 --20664:1:main Tell tool about initial permissions --20664:1:main Initialise scheduler (phase 2) --20664:1:sched sched_init_phase2: tid_main=1, cls_end=0x7ff00ffff, cls_sz=10485760 --20664:1:main Finalise initial image --20664:1:main Initialise signal management --20664:1:mallocfr newSuperblock at 0x402D80000 (pszB 1048544) owner VALGRIND/core --20664:1:main --20664:1:main --20664:1:aspacem <<< SHOW_SEGMENTS: Memory layout at client startup (27 segments, 3 segnames) --20664:1:aspacem ( 0) /net/home/bart/software/valgrind/nightly/valgrind-new/callgrind/callgrind-ppc64-linux --20664:1:aspacem ( 1) /net/home/bart/software/valgrind/nightly/valgrind-new/callgrind/tests/simwork --20664:1:aspacem ( 2) /lib64/ld-2.8.so --20664:1:aspacem 0: RSVN 0000000000-00000fffff 1048576 ----- SmFixed --20664:1:aspacem 1: ANON 0000100000-000011ffff 131072 r-x-- --20664:1:aspacem 2: RSVN 0000120000-0003ffffff 62m ----- SmFixed --20664:1:aspacem 3: 0004000000-000fffffff 192m --20664:1:aspacem 4: file 0010000000-001000ffff 65536 r-x-- d=0x018 i=5985631 o=0 (1) --20664:1:aspacem 5: file 0010010000-001001ffff 65536 rw--- d=0x018 i=5985631 o=0 (1) --20664:1:aspacem 6: anon 0010020000-001002ffff 65536 rwx-- --20664:1:aspacem 7: RSVN 0010030000-001081ffff 8323072 ----- SmLower --20664:1:aspacem 8: 0010820000-0037ffffff 631m --20664:1:aspacem 9: FILE 0038000000-003802ffff 196608 r-x-- d=0x018 i=5985345 o=65536 (0) --20664:1:aspacem 10: file 0038030000-003803ffff 65536 r-x-- d=0x018 i=5985345 o=262144 (0) --20664:1:aspacem 11: FILE 0038040000-003821ffff 1966080 r-x-- d=0x018 i=5985345 o=327680 (0) --20664:1:aspacem 12: FILE 0038220000-003824ffff 196608 rw--- d=0x018 i=5985345 o=2293760 (0) --20664:1:aspacem 13: ANON 0038250000-0038d4ffff 11m rw--- --20664:1:aspacem 14: 0038d50000-0401ffffff 15506m --20664:1:aspacem 15: RSVN 0402000000-040200ffff 65536 ----- SmFixed --20664:1:aspacem 16: ANON 0402010000-0402e7ffff 14m rwx-- --20664:1:aspacem 17: 0402e80000-07fe60ffff 16311m --20664:1:aspacem 18: RSVN 07fe610000-07fefeffff 9m ----- SmUpper --20664:1:aspacem 19: anon 07feff0000-07ff00ffff 131072 rwx-- --20664:1:aspacem 20: 07ff010000-07ffffffff 15m --20664:1:aspacem 21: RSVN 0800000000-8094d2ffff 493901m ----- SmFixed --20664:1:aspacem 22: file 8094d30000-8094d5ffff 196608 r-x-- d=0x013 i=16698662 o=0 (2) --20664:1:aspacem 23: file 8094d60000-8094d7ffff 131072 rw--- d=0x013 i=16698662 o=131072 (2) --20664:1:aspacem 24: RSVN 8094d80000-fffff9fffff 15869g ----- SmFixed --20664:1:aspacem 25: ANON fffffa00000-fffffb4ffff 1376256 rw--- --20664:1:aspacem 26: RSVN fffffb50000-ffffffffffffffff 16383e ----- SmFixed --20664:1:aspacem >>> --20664:1:main --20664:1:main --20664:1:main Running thread 1 --20664:1:syswrap- entering VG_(main_thread_wrapper_NORETURN) --20664:1:aspacem allocated thread stack at 0x402e80000 size 262144 --20664:1:syswrap- run_a_thread_NORETURN(tid=1): pre-thread_wrapper --20664:1:syswrap- thread_wrapper(tid=1): entry --20664:1:transtab allocate sector 0 --20664:1:mallocfr newSuperblock at 0x404910000 (pszB 65504) owner VALGRIND/ttaux 1Uto64(t83) vex: the `impossible' happened: iselIntExpr_R(ppc): cannot reduce tree vex storage: T total 20648 bytes allocated vex storage: P total 288 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). ==20664== at 0x380245B8: report_and_quit (m_libcassert.c:191) ==20664== by 0x3802464B: panic (m_libcassert.c:275) ==20664== by 0x380246BF: vgPlain_core_panic_at (m_libcassert.c:280) ==20664== by 0x380246E3: vgPlain_core_panic (m_libcassert.c:285) ==20664== by 0x3804202B: failure_exit (m_translate.c:674) ==20664== by 0x380D6DD7: vpanic (main_util.c:226) ==20664== by 0x381BB637: iselWordExpr_R (host_ppc_isel.c:1954) ==20664== by 0x381C1A3B: doHelperCall (host_ppc_isel.c:819) ==20664== by 0x381C3C3F: iselSB_PPC (host_ppc_isel.c:3996) ==20664== by 0x380D53E7: LibVEX_Translate (main_main.c:590) ==20664== by 0x3803EE7B: vgPlain_translate (m_translate.c:1518) ==20664== by 0x38069A93: vgPlain_scheduler (scheduler.c:857) ==20664== by 0x380A4B8B: run_a_thread_NORETURN (syswrap-linux.c:94) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==20664== at 0x8094D35CC0: _dl_start (in /lib64/ld-2.8.so) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. Reproducible: Always Steps to Reproduce: See above. Actual Results: Assertion failure. Expected Results: Test running fine.
> 1Uto64(t83) > vex: the `impossible' happened: > iselIntExpr_R(ppc): cannot reduce tree This must be the guard widening stuff for the branch predictor. The code is copied from cachegrind, but it seems cachegrind has no test running the branch prediction simulation, so this problem was not discovered in the past. However, I am neither familiar with VEX, nor do I have a PPC machine...
Set to want3.6.0. I don't have time to fix it in the next few days. Bart, you might be able to kludge around it by adding Iop_1Uto64 to the case in guest_ppc_isel.c which currently handles Iop_1Uto32 and Iop_1Uto8, but I don't think that's a proper fix. (A proper fix would involve making sure PPCInstr_Set works properly in 64-bit mode). Or, you could handle Iop_1Uto64 exactly the same as Iop_1Uto32 but then emit two instructions to shift the result register left by 32 and then (unsignedly) right by 32. This would generate pretty bad code but it would work.
(In reply to comment #2) > but then emit two instructions to shift the result register left by > 32 and then (unsignedly) right by 32. .. and you can figure out how to do that by looking at the instructions created by host_ppc_isel.c for Iop_Shl64 and Iop_Shr64.
Currently this does not seem to fail on a Power 10 system, Fedora release 38, valgrind 3.22