https://bugs.kde.org/show_bug.cgi?id=369175
--- Comment #3 from Julian Seward <jsew...@acm.org> --- This kind of thing could well be due to incorrect register allocation around the calls, perhaps corrupting the values passed to the calls or corrupting values in registers around the call site, that both caller and callee expect the other to preserve. Maybe something along those lines. I tried to reproduce this on gcc112.fsffrance.org (a P8 system) but failed -- it runs OK. I'd be happy to chase this if I could reproduce on a machine that I can access. Failing that .. I'd suggest: (1) make the smallest possible testcase that segfaults (2) make sure it still segfaults with --tool=none (3) with --tool=none, run it with --trace-flags=10001110 and --trace-notbelow= set to the appropriate value so you actually get output for the failing block. From that we might be able to guess what the problem is. (4) Find the failing instruction in GDB by setting env var VALGRIND_LAUNCHER= (to nothing) and then running gdb none/none-ppc64be-linux run --tool=none ./path/to/the/test/binary and disassemble say 10 insns each side of the failing insn, so we can locate it in the JIT generated code. Be aware that GDB may catch segfaults that are unrelated to this crash, prior to the crash point; allow it to pass those on to valgrind to be handled. (5) Post the results from (3) and (4) here. -- You are receiving this mail because: You are watching all bug changes.
