Created attachment 25649 [details] Test case, part 1 The libffi test-suite is failing on an e500v2 build of GCC 4.6.1 with a segmentation fault in libgcc (called from "throw()" in the "unwindtest.cc" file). The target GCC configure options: --build/--host/--target=powerpc-linux-gnuspe --with-cpu=8548 --enable-e500_double --with-long-double-128 I have extracted it to the attached minimal test-case, compiled as follows: $ g++ -Wall -Wextra -Werror -ggdb3 -Os -c unwindtest.cc -o unwindtest.o $ g++ -Wall -Wextra -Werror -ggdb3 -Os -c unwindtestfunc.cc -o unwindtestfunc.o $ g++ -ggdb3 -Os -o unwindtest unwindtest.o unwindtestfunc.o The test fails if "unwindtestfunc.cc" is built with "-Os", but not if it is built with "-O2". The compile options for unwindtest.cc have no effect on the success or failure of the test. Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/
Created attachment 25650 [details] Test case, part 2
Created attachment 25651 [details] Assembled unwindtestfunc.cc (with -O2)
Created attachment 25652 [details] Assembled unwindtestfunc.cc (with -Os)
_Z16closure_test_fn1P7ffi_cifPvPS1_S1_: .LFB0: .file 1 "unwindtestfunc.cc" .loc 1 17 0 .cfi_startproc .LVL0: stwu 1,-128(1) .LCFI0: .cfi_def_cfa_offset 128 mflr 0 mr 3,6 .LVL1: stw 0,132(1) addi 11,1,-16 .LCFI1: .cfi_def_cfa 11, 160 That last .cfi directive is wrong. To match the instructions it should be .cfi_def_cfa 11, 144
bl _save64gpr_24 .loc 1 17 0 mr 31,4 .cfi_offset 31, -100 .cfi_offset 1231, -104 .cfi_offset 30, -108 .cfi_offset 1230, -112 .cfi_offset 29, -116 .cfi_offset 1229, -120 .cfi_offset 28, -124 .cfi_offset 1228, -128 .cfi_offset 27, -132 .cfi_offset 1227, -136 .cfi_offset 26, -140 .cfi_offset 1226, -144 .cfi_offset 25, -148 .cfi_offset 1225, -152 .cfi_offset 24, -156 .cfi_offset 1224, -160 These are all wrong too, I think. .loc 1 26 0 lwz 9,0(5) .loc 1 17 0 mr 11,5 Yikes!! Using r11 for something else, but no cfi directive to say the frame is no longer in r11.
Created attachment 25692 [details] Archive of RTL dumps of failing testcase built with "-Os" I spent some time looking through the RTL dump. It looks like the stack references first show up in 194r.split2, but I couldn't understand enough of what I was looking at to match it up with the assembly output or figure out where the CFI information went wrong. I've attached a tar.gz of the RTL dumps in case that helps isolate the issue. Cheers, Kyle Moffett
There are multiple problems in TARGET_SPE_ABI parts of rs6000_emit_prologue. Hacking on it.
Created attachment 25702 [details] Proposed mainline fix
Created attachment 25703 [details] gcc-4.6 fix
Please test out these patches. bootstrap and regression tests with -Os in BOOT_CFLAGS on spe would be ideal. I'll be running a powerpc-linux regression test, but can't do that for spe.
Ok, I'm running a "bootstrap-lean" + "make check" by way of a full Debian GCC package build with this patch added. The first build will just do C/C++/ObjC/ObjC++/Fortran; if that works out OK I will also do a Java build in a little while. I applied a 1-line patch to make the package build set "BOOT_CFLAGS := -g -O2" as you requested, so hopefully any fallout will be obvious during the GCC build itself. There are 2 other patches I have applied on top of the Debian GCC 4.6.2-3 package to fix the SPE build: * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647288 * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647324 The libffi one applies on top of these patches already in the Debian package: * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644338 Based on the speed of this board and the fact that I am using it for other testing as well, I expect to have the test results in roughly 6-8 hours. Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/
Created attachment 25711 [details] mainline fix Revised patch. I'd forgotten that you can't compare hard reg rtx's, ever since 2002-06-16 Jeff Law <law@redhat.com> * emit-rtl.c (gen_rtx_REG): Temporarily turn off automatic sharing of hard registers. Some "temporarily" that turned out to be. :)
Created attachment 25712 [details] gcc-4.6 fix
I'm now rebuilding the Debian GCC 4.6.2-4 (which now includes the other 2 patches I mentioned previously) with the updated 4.6 patch, I'll let you know what the results are (including testsuite deltas between unpatched-O2, patched-O2, and patched-Os). I probably won't have any results for you before Monday. Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/
Sorry for the delay. I've suddenly started experiencing odd kernel panics on my test boards in the middle of the test-suite runs and I'm in the process of tracking them down. Based on where the kernel is crashing I don't think it's caused by the GCC changes, just bad luck that I didn't notice this bug before. From the test suites that have completed so far, I'm not seeing any new FAILs relative to the old GCC, but I have to wait for them all to finish in order to be able to diff properly. I'll let you know when I have something to report. Cheers, Kyle Moffett
@Kyle: wrt random kernel panics, I had them too on my P2020RDB and attributed them to RAM errors. Before they happen, the kernel already complains about corrupt data in the logs and GCC randomly crashes when running a sufficiently large parallel build. After power-cycling the GCC crashes usually vanish, so maybe there's a small chance that DDR RAM is slightly miscalibrated by u-boot? Reducing the DDR clock might help.
Ok, a new kernel based on 3.2-rc1 resolved my crashing issues entirely. I wasn't too worried about my DDR clocks since I have ECC memory and EDAC never reported any errors. Using the gcc-4.6 fix on top of 4.6.2, I get the following diffs in the testsuite summary between 4.6.2-unpatched and 4.6.2-patched. I'm in the process of running a second build with BOOT_CFLAGS="-Os", but I'll be out of the office for Thanksgiving until next Monday and probably won't be able to check on it during that time. These appear to be EH bugs fixed by your changes: -FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -Os execution test -FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -Os execution test -FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -Os execution test -FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -Os execution test These are tests that shouldn't be run on e500/SPE as they build with "-mcpu=power5". These tests fail with SIGILL while executing an "lfd" opcode; I'm not sure why they passed before: +FAIL: gcc.target/powerpc/ppc-fma-5.c execution test +FAIL: gfortran.dg/pr47614.f -O0 execution test +FAIL: gfortran.dg/pr47614.f -O1 execution test +FAIL: gfortran.dg/pr47614.f -O2 execution test +FAIL: gfortran.dg/pr47614.f -O3 -fomit-frame-pointer execution test +FAIL: gfortran.dg/pr47614.f -O3 -fomit-frame-pointer -funroll-loops +FAIL: gfortran.dg/pr47614.f -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test +FAIL: gfortran.dg/pr47614.f -O3 -g execution test +FAIL: gfortran.dg/pr47614.f -Os execution test There's no other delta in the testsuite summary, so I feel pretty confident that there were no regressions introduced by this patch for e500 at least. Thanks again for your help! Cheers, Kyle Moffett
I am happy to report that your updated 4.6.2 patch seems to be 100% functional on e500/SPE. I get identical "test-summary" reports for patched-4.6.2 with and without BOOT_CFLAGS="-g -Os", apart from the different build directory paths (EG: /srv/build/gcc-4.6-normal versus /srv/build/gcc-4.6-Os), As before, the following testsuite failures are fixed relative to unpatched 4.6.2: -FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -Os execution test -FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -Os execution test -FAIL: g++.dg/torture/stackalign/eh-vararg-1.C -Os execution test -FAIL: g++.dg/torture/stackalign/eh-vararg-2.C -Os execution test And again, as before, the following 64-bit-only tests are erroneously run on 32-bit e500 CPUs, although they were inexplicably successful during a previous build. +FAIL: gcc.target/powerpc/ppc-fma-5.c execution test +FAIL: gfortran.dg/pr47614.f -O0 execution test +FAIL: gfortran.dg/pr47614.f -O1 execution test +FAIL: gfortran.dg/pr47614.f -O2 execution test +FAIL: gfortran.dg/pr47614.f -O3 -fomit-frame-pointer execution test +FAIL: gfortran.dg/pr47614.f -O3 -fomit-frame-pointer -funroll-loops +FAIL: gfortran.dg/pr47614.f -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test +FAIL: gfortran.dg/pr47614.f -O3 -g execution test +FAIL: gfortran.dg/pr47614.f -Os execution test Thanks again for your help! Cheers, Kyle Moffett
Author: amodra Date: Tue Dec 6 03:41:44 2011 New Revision: 182039 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182039 Log: PR target/50906 * config/rs6000/rs6000.c (rs6000_emit_prologue <TARGET_SPE_ABI>): Do not mark r11 setup as frame-related. Pass correct offset to rs6000_emit_savres_rtx. Correct out-of-line rs6000_frame_related arguments. Correct sp_offset. Remove "offset" fudge from in-line rs6000_frame_related call. Rename misleading variable. Fix comments and whitespace. Tidy some expressions. (rs6000_emit_epilogue <TARGET_SPE_ABI>): Always set frame_reg_rtx to r11 in out-of-line case. Correct sp_offset. Pass correct offset to rs6000_emit_savres_rtx. Rename misleading variable. Fix comments and whitespace. Tidy some expressions. (rs6000_emit_epilogue <non-TARGET_SPE_ABI>): Add sp_offset adjustment when !saving_GPRs_inline. Correct register mode used in address calcs. (rs6000_emit_epilogue <non-TARGET_SPE_ABI>): Similarly when !restoring_GPRs_inline. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
Author: amodra Date: Tue Dec 6 03:47:37 2011 New Revision: 182040 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182040 Log: PR target/50906 * config/rs6000/rs6000.c (rs6000_emit_prologue <TARGET_SPE_ABI>): Do not mark r11 setup as frame-related. Pass correct offset to rs6000_emit_savres_rtx. Correct out-of-line rs6000_frame_related arguments. Correct sp_offset. Remove "offset" fudge from in-line rs6000_frame_related call. Rename misleading variable. Fix comments and whitespace. Tidy some expressions. (rs6000_emit_epilogue <TARGET_SPE_ABI>): Always set frame_reg_rtx to r11 in out-of-line case. Correct sp_offset. Pass correct offset to rs6000_emit_savres_rtx. Rename misleading variable. Fix comments and whitespace. Tidy some expressions. (rs6000_emit_epilogue <non-TARGET_SPE_ABI>): Add sp_offset adjustment when !saving_GPRs_inline. Correct register mode used in address calcs. (rs6000_emit_epilogue <non-TARGET_SPE_ABI>): Similarly when !restoring_GPRs_inline. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/rs6000/rs6000.c
patch applied 4.7 and 4.6