Recent contributions between "4.7.0 20110702 (experimental) [trunk revision 175781]" and "4.7.0 20110708 (experimental) [trunk revision 176030]" severely regressed many execution tests in the testsuite. [1] http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00261.html [2] http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg00989.html Authors of suspected commits (probably dwarf2 rewrite, since exceptions are not working at all) added to CC.
Created attachment 24765 [details] asm source that compiles to bad executable This asm was produced by compiling gcc.dg/cleanup-10.c with -fexceptions -fnon-call-exceptions -O2 compile flags.
Created attachment 24766 [details] asm source that compiles to good executable
Two attached sources were created with GOOD: GCC: (GNU) 4.7.0 20110708 (experimental) [trunk revision 176025] BAD : GCC: (GNU) 4.7.0 20110707 (experimental) [trunk revision 176014] 00:17 r176025 - /trunk/gcc/DATESTAMP gccadmin 00:17 r176024 - /branches/gcc-4_6-branch/gcc/DATESTAMP gccadmin 00:17 r176023 - /branches/gcc-4_5-branch/gcc/DATESTAMP gccadmin 00:16 r176022 - /branches/gcc-4_4-branch/gcc/DATESTAMP gccadmin 00:14 r176021 - in /trunk/gcc: ChangeLog config/alpha... rth 00:13 r176020 - in /trunk/gcc: ChangeLog Makefile.in ... rth 00:05 r176019 - in /trunk/gcc: ChangeLog ada/ChangeLo... rth July 07, 2011 23:57 r176018 - in /trunk/gcc: ChangeLog dwarf2cfi.c ... rth 23:51 r176017 - in /trunk/gcc: ChangeLog dwarf2cfi.c ... rth 23:42 r176016 - in /trunk/gcc: ChangeLog dwarf2cfi.c ... rth 23:35 r176015 - in /trunk/gcc: ChangeLog Makefile.in ... rth 21:55 r176014 - in /branches/gcc-4_6-branch/gcc: cp/C... jason
Created attachment 24767 [details] bad executable, contents of the .eh_frame section bad: file format elf64-alpha Contents of the .eh_frame section:
Created attachment 24768 [details] good executable, contents of the .eh_frame section good: file format elf64-alpha Contents of the .eh_frame section:
Are you sure these were configured the same way? One of the output files is using .cfi directives while the other isn't. Could you post a .i file? cleanup-10.c needs headers...
Created attachment 24769 [details] Preprocessed source. Gzipped cleanup-10.i preprocessed source.
(In reply to comment #6) > Are you sure these were configured the same way? One of the output files is > using .cfi directives while the other isn't. Yes, compiler is configured and built the same way in both cases. > Could you post a .i file? cleanup-10.c needs headers... Done.
(In reply to comment #6) > Are you sure these were configured the same way? One of the output files is > using .cfi directives while the other isn't. Lack of .cfi was caused by that MIPS_DEBUGGING_INFO thing leaking into alpha/elf.h that I fixed recently.
Well, the new use of .cfi directives probably comes from this bit that was committed in between the two revisions: Index: gcc/config/alpha/elf.h =================================================================== --- gcc/config/alpha/elf.h (revision 176014) +++ gcc/config/alpha/elf.h (revision 176025) @@ -25,8 +25,9 @@ along with GCC; see the file COPYING3. /* ??? Move all SDB stuff from alpha.h to osf.h. */ #undef SDB_DEBUGGING_INFO +#undef MIPS_DEBUGGING_INFO +#undef DBX_DEBUGGING_INFO -#define DBX_DEBUGGING_INFO 1 #define DWARF2_DEBUGGING_INFO 1 #undef PREFERRED_DEBUGGING_TYPE Can you revert that and try again?
Created attachment 24771 [details] asm source at r176020 Indeed, reverting the patch from Comment 10 fixed cleanup-10.c execution failure! I am bootstrapping and regtesting the compiler with the patch reverted.
Just guessing now, but you might also want to try a different version of binutils - maybe there's a problem with .cfi directive handling? Or maybe this has just never been tested with an alpha gas due to the MIPS_DEBUGGING_INFO?
(In reply to comment #12) > Just guessing now, but you might also want to try a different version of > binutils - maybe there's a problem with .cfi directive handling? Due to some other ld problems, I am testing with LD_FOR_TARGET: GNU ld (GNU Binutils) 2.21.52.20110623 > Or maybe this has just never been tested with an alpha gas due to the > MIPS_DEBUGGING_INFO? rth will know this better than I ...
Well, .cfi handling in gas isn't totally untested because there's plenty of glibc asm files that use it. But I have to concede that there might be a bug. We'll have to examine the actual generated unwind info with and without the change.
Results with a patched compiler [1], no regressions. [1] http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg01678.html
Still happens with unpatched compiler, gcc 4.7.0 20110801 [1]. [1] http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00190.html
Mine.
Argh. The problem is that if we emit both .ent / .frame / .mask / .end notes and .cfi directives, the .cfi directives get ignored. Thus the .cfi_personality directive did not in fact register a personality, so no exceptions ever get caught. I'll see if I can make the assembler DTRT, or at minimum generate some sort of error message and then change the compiler to match.
Err, it's slightly more complicated than that. We're emitting *both* a frame from .ent/.end *and* a frame from .cfi. The later has the personality info, and the former does not. And of course it's going to be more or less random which one the binary search picks up at runtime.
http://sourceware.org/ml/binutils/2011-08/msg00052.html
(In reply to comment #20) > http://sourceware.org/ml/binutils/2011-08/msg00052.html Works ok on native alpha [1]. There are two remaining problems, an assert in "as", as reported in [2] FAIL: g++.dg/tree-prof/partition2.C compilation, -Os -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition2.C execution, -Os -fprofile-use /tmp/cccx2jTq.s: Assembler messages:^M /tmp/cccx2jTq.s:122: Error: invalid operands (.text.unlikely and .text.startup sections) for `-'^M /home/uros/bin/as: BFD (GNU Binutils) 2.21.52.20110623 assertion fail elf.c:2826^M g++: internal compiler error: Segmentation fault (program as)^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See <http://gcc.gnu.org/bugs.html> for instructions.^M compiler exited with status 1 and FAIL: g++.dg/tree-prof/partition1.C compilation, -g -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution, -g -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O0 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution, -O0 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O1 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution, -O1 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O2 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution, -O2 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution, -O3 -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -g -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution, -O3 -g -fprofile-use FAIL: g++.dg/tree-prof/partition1.C compilation, -Os -fprofile-use (internal compiler error) UNRESOLVED: g++.dg/tree-prof/partition1.C execution, -Os -fprofile-use /home/uros/gcc-svn/trunk/gcc/testsuite/g++.dg/tree-prof/partition1.C: In function 'void foo()':^M /home/uros/gcc-svn/trunk/gcc/testsuite/g++.dg/tree-prof/partition1.C:46:1: internal compiler error: in reload_combine_note_use, at postreload.c:1538^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See <http://gcc.gnu.org/bugs.html> for instructions.^M [1] http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00614.html [2] http://sourceware.org/ml/binutils/2011-08/msg00056.html
(In reply to comment #21) > There are two remaining problems, an assert in "as", as reported in [2] > > FAIL: g++.dg/tree-prof/partition2.C compilation, -Os -fprofile-use (internal > compiler error) > UNRESOLVED: g++.dg/tree-prof/partition2.C execution, -Os -fprofile-use This is PR 49972, reportedly fixed in binutils [1]. > FAIL: g++.dg/tree-prof/partition1.C compilation, -g -fprofile-use (internal > compiler error) > UNRESOLVED: g++.dg/tree-prof/partition1.C execution, -g -fprofile-use > FAIL: g++.dg/tree-prof/partition1.C compilation, -O0 -fprofile-use (internal > compiler error) > UNRESOLVED: g++.dg/tree-prof/partition1.C execution, -O0 -fprofile-use > FAIL: g++.dg/tree-prof/partition1.C compilation, -O1 -fprofile-use (internal > compiler error) > UNRESOLVED: g++.dg/tree-prof/partition1.C execution, -O1 -fprofile-use > FAIL: g++.dg/tree-prof/partition1.C compilation, -O2 -fprofile-use (internal > compiler error) > UNRESOLVED: g++.dg/tree-prof/partition1.C execution, -O2 -fprofile-use > FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -fprofile-use (internal > compiler error) > UNRESOLVED: g++.dg/tree-prof/partition1.C execution, -O3 -fprofile-use > FAIL: g++.dg/tree-prof/partition1.C compilation, -O3 -g -fprofile-use > (internal compiler error) > UNRESOLVED: g++.dg/tree-prof/partition1.C execution, -O3 -g -fprofile-use > FAIL: g++.dg/tree-prof/partition1.C compilation, -Os -fprofile-use (internal > compiler error) > UNRESOLVED: g++.dg/tree-prof/partition1.C execution, -Os -fprofile-use This is now reported as PR 50001. [1] http://sourceware.org/ml/binutils/2011-08/msg00057.html
(In reply to comment #22) > This is PR 49972, reportedly fixed in binutils [1]. Er, the ice in gas with invalid .gcc_except_table is fixed in binutis.
Testsuite results are clean with patched gas. Fixed.