|
From: Carl E. L. <ce...@us...> - 2015-09-14 17:41:58
|
On Sat, 2015-09-12 at 22:46 +0200, Florian Krohm wrote: > 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? I checked with Peter on the compiler team and the "divweu" is supported by ppc32 hardware. The 64-bit dividend is stored in two 32-bit registers. This does seem to be in conflict with the doc that you pointed me at. Unfortunately, I don't have access to a real ppc32 machine to properly test this on the HW. So, at the moment I would say testing the iop Iop_DivU32E which generates the divweu instruction on ppc32 HW should succeed. Peter, do you agree? Carl Love |