|
From: Florian K. <fl...@ei...> - 2015-09-12 20:46:48
|
On 12.09.2015 22:10, Mark Wielaard wrote: > On Sat, 2015-09-12 at 20:42 +0200, Florian Krohm wrote: >> On 12.09.2015 17:23, Mark Wielaard wrote: >> >>> All I can offer you at the moment is the unfiltered output: >>> >>> :::::::::::::: >>> memcheck/tests/vbit-test/vbit-test.stderr.out.unfiltered.out >>> :::::::::::::: >>> ==8767== >>> ==8767== Process terminating with default action of signal 4 (SIGILL) >>> ==8767== Illegal opcode at address 0x834D26BC >>> ==8767== at 0x100076F4: valgrind_vex_inject_ir (valgrind.c:85) >>> ==8767== by 0x100076F4: valgrind_execute_test (valgrind.c:111) >>> ==8767== by 0x10001D27: test_binary_op (binary.c:461) >>> ==8767== by 0x10000BCB: main (main.c:135) >>> >>> So it crashed at the VALGRIND_VEX_INJECT_IR for some reason. >>> >> >> That would suggest that the injected code is invalid for ppc32. >> Can you rerun with: >> >> Index: memcheck/tests/vbit-test/vbit-test.vgtest >> =================================================================== >> --- memcheck/tests/vbit-test/vbit-test.vgtest (revision 15647) >> +++ memcheck/tests/vbit-test/vbit-test.vgtest (working copy) >> @@ -1,2 +1,3 @@ >> prog: vbit-test >> vgopts: -q >> +args: -v -v >> >> The .out file should tell which IROp is causing it. > > :::::::::::::: > memcheck/tests/vbit-test/vbit-test.stdout.out > :::::::::::::: .... > Testing operator Iop_DivU32E > Ah yes.. In host_ppc_isel.c around line 1538 a PPCInstr_Div with extended == 1 is created for tat IROp. Then in host_ppc_defs.c around line 4082 a divweu is generated for that. That seems to be an insn that is only available for power7 and newer. I do not know that for sure but http://www-01.ibm.com/support/knowledgecenter/SSGH4D_14.1.0/com.ibm.xlf141.aix.doc/language_ref/divwe.html says so for divwe (which is for signed extended division). I'd say, this is a bug in the powerpc port. Carl, what do you think? Florian |