[Bug lto/45702] [4.6 Regression] New LTO test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702 John David Anglin changed: What|Removed |Added Priority|P2 |P3 --- Comment #25 from John David Anglin 2010-11-23 23:51:07 UTC --- This is resolved on hppa, so changing status to fixed.
[Bug lto/45702] [4.6 Regression] New LTO test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #24 from Richard Guenther 2010-11-04 11:11:03 UTC --- Should be fixed now.
[Bug lto/45702] [4.6 Regression] New LTO test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702 --- Comment #23 from Richard Guenther 2010-11-04 11:10:25 UTC --- Author: rguenth Date: Thu Nov 4 11:10:21 2010 New Revision: 166305 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166305 Log: 2010-11-04 Richard Guenther PR testsuite/45702 * gcc.dg/pr34989-1.c: Move ... * gcc.dg/lto/pr34989-1_0.c: ... here. * gcc.dg/pr34989-2.c: Move ... * gcc.dg/lto/pr34989-1_1.c: ... here. * gcc.dg/pr27898.c: Move ... * gcc.dg/lto/pr27898_0.c: ... here and ... * gcc.dg/lto/pr27898_1.c: ... split. * gcc.dg/pr28712.c: Move ... * gcc.dg/lto/pr28712_0.c: ... here and ... * gcc.dg/lto/pr28712_1.c: ... split ... * gcc.dg/lto/pr28712_2.c: ... twice. * gcc.dg/pr28706.c: Move ... * gcc.dg/lto/pr28706_0.c: ... here and ... * gcc.dg/lto/pr28706_1.c: ... split. Added: trunk/gcc/testsuite/gcc.dg/lto/pr27898_0.c - copied, changed from r166302, trunk/gcc/testsuite/gcc.dg/pr27898.c trunk/gcc/testsuite/gcc.dg/lto/pr27898_1.c trunk/gcc/testsuite/gcc.dg/lto/pr28706_0.c - copied, changed from r166302, trunk/gcc/testsuite/gcc.dg/pr28706.c trunk/gcc/testsuite/gcc.dg/lto/pr28706_1.c trunk/gcc/testsuite/gcc.dg/lto/pr28712_0.c - copied, changed from r166302, trunk/gcc/testsuite/gcc.dg/pr28712.c trunk/gcc/testsuite/gcc.dg/lto/pr28712_1.c trunk/gcc/testsuite/gcc.dg/lto/pr28712_2.c trunk/gcc/testsuite/gcc.dg/lto/pr34989-1_0.c - copied, changed from r166302, trunk/gcc/testsuite/gcc.dg/pr34989-1.c trunk/gcc/testsuite/gcc.dg/lto/pr34989-1_1.c - copied, changed from r166302, trunk/gcc/testsuite/gcc.dg/pr34989-2.c Removed: trunk/gcc/testsuite/gcc.dg/pr27898.c trunk/gcc/testsuite/gcc.dg/pr28706.c trunk/gcc/testsuite/gcc.dg/pr28712.c trunk/gcc/testsuite/gcc.dg/pr34989-1.c trunk/gcc/testsuite/gcc.dg/pr34989-2.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug lto/45702] [4.6 Regression] New LTO test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 CC||jakub at gcc dot gnu.org
[Bug lto/45702] [4.6 Regression] New LTO test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702 --- Comment #22 from rguenther at suse dot de 2010-10-04 08:51:36 UTC --- On Mon, 4 Oct 2010, danglin at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702 > > --- Comment #21 from John David Anglin > 2010-10-04 00:41:15 UTC --- > Still have the following fails on hppa-unknown-linux-gnu: > > FAIL: gcc.dg/pr27898.c (test for excess errors) > FAIL: gcc.dg/pr28706.c (test for excess errors) > FAIL: gcc.dg/pr28712.c (test for excess errors) > FAIL: gcc.dg/pr34989-1.c (test for excess errors) > > /home2/dave/opt/gnu/bin/ld: cannot find -lm Yep - those are more "interesting" to fix. I'll either move them to the lto testsuite or remove them.
[Bug lto/45702] [4.6 Regression] New LTO test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702 --- Comment #21 from John David Anglin 2010-10-04 00:41:15 UTC --- Still have the following fails on hppa-unknown-linux-gnu: FAIL: gcc.dg/pr27898.c (test for excess errors) FAIL: gcc.dg/pr28706.c (test for excess errors) FAIL: gcc.dg/pr28712.c (test for excess errors) FAIL: gcc.dg/pr34989-1.c (test for excess errors) /home2/dave/opt/gnu/bin/ld: cannot find -lm
[Bug lto/45702] [4.6 Regression] New LTO test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702 --- Comment #20 from Richard Guenther 2010-09-30 12:22:41 UTC --- Author: rguenth Date: Thu Sep 30 12:22:33 2010 New Revision: 164749 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164749 Log: 2010-09-30 Richard Guenther PR testsuite/45702 * gcc.dg/debug/pr41893-1.c: Adjust. * gcc.dg/pr30762-1.c: Likewise. * gcc.dg/pr31529-1.c: Likewise. * gcc.dg/pr34457-1.c: Likewise. * gcc.dg/pr34668-1.c: Likewise. * gcc.dg/pr43557-1.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/debug/pr41893-1.c trunk/gcc/testsuite/gcc.dg/pr30762-1.c trunk/gcc/testsuite/gcc.dg/pr31529-1.c trunk/gcc/testsuite/gcc.dg/pr34457-1.c trunk/gcc/testsuite/gcc.dg/pr34668-1.c trunk/gcc/testsuite/gcc.dg/pr43557-1.c
[Bug lto/45702] [4.6 Regression] New LTO test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #19 from Richard Guenther 2010-09-29 15:38:35 UTC --- Mine.
[Bug lto/45702] [4.6 Regression] New LTO test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #18 from Rainer Orth 2010-09-27 17:44:09 UTC --- *-*-solaris2* is equally affected. There doesn't even exist a static libm.a. For other LTO tests, this is handled by lib/lto.exp (lto_init) which temporarily removes -lm from the link.
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2010-09-21 20:40 --- Subject: Re: [4.6 Regression] New LTO test failures > > Similar errors on hppa2.0w-hp-hpux11.11. Excess errors are: > > > > cc1: error: LTO support has not been enabled in this configuration > > cc1: error: LTO support has not been enabled in this configuration > > the effective target check should avoid that. Why does it not work > for you? It seems configure enables LTO by default if it doesn't find a reason to disable it. ENABLE_LTO is defined in auto-host.h. It can be disabled with a configure option, but I think the default should be changed on hppa*-*-hpux*. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #16 from rguenther at suse dot de 2010-09-21 08:44 --- Subject: Re: [4.6 Regression] New LTO test failures On Tue, 21 Sep 2010, danglin at gcc dot gnu dot org wrote: > --- Comment #15 from danglin at gcc dot gnu dot org 2010-09-21 00:44 > --- > Similar errors on hppa2.0w-hp-hpux11.11. Excess errors are: > > cc1: error: LTO support has not been enabled in this configuration > cc1: error: LTO support has not been enabled in this configuration the effective target check should avoid that. Why does it not work for you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #15 from danglin at gcc dot gnu dot org 2010-09-21 00:44 --- Similar errors on hppa2.0w-hp-hpux11.11. Excess errors are: cc1: error: LTO support has not been enabled in this configuration cc1: error: LTO support has not been enabled in this configuration -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #14 from hjl dot tools at gmail dot com 2010-09-20 17:10 --- One solution is always pass -L to linker even if the directory is known to linker. Gcc always does that for multi-lib. This will make gcc more consistent. It may also allow using system linker with native sysroot toolchain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #13 from hjl dot tools at gmail dot com 2010-09-20 16:56 --- Here is the deal: 1. The linker default search paths are /lib, /usr/lib. 2. "ld -r" disables the linker default search paths. 3. Gcc always passes -Lmulti-lib-dir to ld when multi-lib is enabled. On Linux/ia32, gcc never passes -L/lib -L/usr/lib to linker. It works with the linker default search paths. But "gcc -r" disables the linker default search paths and "gcc -r -lm" doesn't work. On Linux/x86-64, gcc always passes -Lmulti-lib-dir to linker and "gcc -r -lm" works with -m32/-m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #12 from rguenther at suse dot de 2010-09-17 14:14 --- Subject: Re: [4.6 Regression] New LTO test failures On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote: > --- Comment #11 from hjl dot tools at gmail dot com 2010-09-17 14:11 > --- > (In reply to comment #9) > > Subject: Re: [4.6 Regression] New LTO test failures > > > > On Fri, 17 Sep 2010, jakub at gcc dot gnu dot org wrote: > > > > > --- Comment #8 from jakub at gcc dot gnu dot org 2010-09-17 14:04 > > > --- > > > Dejagnu adds it always for dg-do link/run, and there doesn't seem to be a > > > way > > > to bypass that. > > > > Hm, so I'd say blame it on the host system of HJ. Or alternatively > > As I said, it is a REGRESSION, which means it passed before. > I believe it is caused by your --combine change. See: > > http://gcc.gnu.org/ml/gcc-regression/2010-09/msg00267.html Of course it is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #11 from hjl dot tools at gmail dot com 2010-09-17 14:11 --- (In reply to comment #9) > Subject: Re: [4.6 Regression] New LTO test failures > > On Fri, 17 Sep 2010, jakub at gcc dot gnu dot org wrote: > > > --- Comment #8 from jakub at gcc dot gnu dot org 2010-09-17 14:04 > > --- > > Dejagnu adds it always for dg-do link/run, and there doesn't seem to be a > > way > > to bypass that. > > Hm, so I'd say blame it on the host system of HJ. Or alternatively As I said, it is a REGRESSION, which means it passed before. I believe it is caused by your --combine change. See: http://gcc.gnu.org/ml/gcc-regression/2010-09/msg00267.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-17 14:11:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #10 from hjl dot tools at gmail dot com 2010-09-17 14:08 --- (In reply to comment #6) > With -r -nostdlib when -lm is mentioned on the command line, it is looking for > libm.a. Guess you have it installed on one box and not on the other one. > That said, the tests really shouldn't have -lm on their link line. > /usr/lib/libm.a is available. 32bit gcc driver doesn't pass -L/usr/lib to ld and 64bit gcc driver does. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #9 from rguenther at suse dot de 2010-09-17 14:07 --- Subject: Re: [4.6 Regression] New LTO test failures On Fri, 17 Sep 2010, jakub at gcc dot gnu dot org wrote: > --- Comment #8 from jakub at gcc dot gnu dot org 2010-09-17 14:04 --- > Dejagnu adds it always for dg-do link/run, and there doesn't seem to be a way > to bypass that. Hm, so I'd say blame it on the host system of HJ. Or alternatively add an empty main() to each of the testcases to be able to drop -r -nostdlib. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #8 from jakub at gcc dot gnu dot org 2010-09-17 14:04 --- Dejagnu adds it always for dg-do link/run, and there doesn't seem to be a way to bypass that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #7 from rguenther at suse dot de 2010-09-17 13:58 --- Subject: Re: [4.6 Regression] New LTO test failures On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote: > --- Comment #5 from hjl dot tools at gmail dot com 2010-09-17 13:52 > --- > Works fine in 64bit with -m32 > > [...@gnu-6 gcc]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc > -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ > /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -flto -r > -nostdlib > /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c > /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -lm -m32 -o > pr28712.exe > [...@gnu-6 gcc]$ > > Failed on ia32. > > [...@gnu-6 gcc]$ /export/build/gnu/gcc-32bit/build-i686-linux/gcc/xgcc > -B/export/build/gnu/gcc-32bit/build-i686-linux/gcc/ > /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -flto -r > -nostdlib > /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c > /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -lm -o > pr28712.exe > /usr/local/bin/ld: cannot find -lm > collect2: ld returned 1 exit status > [...@gnu-6 gcc]$ The question is, why do we add -lm with -nostdlib anways? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #6 from jakub at gcc dot gnu dot org 2010-09-17 13:57 --- With -r -nostdlib when -lm is mentioned on the command line, it is looking for libm.a. Guess you have it installed on one box and not on the other one. That said, the tests really shouldn't have -lm on their link line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #5 from hjl dot tools at gmail dot com 2010-09-17 13:52 --- Works fine in 64bit with -m32 [...@gnu-6 gcc]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -flto -r -nostdlib /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -lm -m32 -o pr28712.exe [...@gnu-6 gcc]$ Failed on ia32. [...@gnu-6 gcc]$ /export/build/gnu/gcc-32bit/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc-32bit/build-i686-linux/gcc/ /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -flto -r -nostdlib /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -lm -o pr28712.exe /usr/local/bin/ld: cannot find -lm collect2: ld returned 1 exit status [...@gnu-6 gcc]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #4 from rguenther at suse dot de 2010-09-17 13:48 --- Subject: Re: [4.6 Regression] New LTO test failures On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote: > --- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 13:36 > --- > -m32 works on Intel64 since gcc driver passes > > /export/build/gnu/gcc/build-x86_64-linux/gcc/collect-ld --eh-frame-hdr -m > elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o pr28712.exe -r > -L/export/build/gnu/gcc/build-x86_64-linux/gcc/32 -L/lib/../lib > -L/usr/lib/../lib -L/export/build/gnu/gcc/build-x86_64-linux/gcc > /tmp/ccLRsGQH.lto.o -lm > > to collect-ld. Only ia32 fails. Hm. Maybe the -nostdlib I added causes this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-17 13:36 --- -m32 works on Intel64 since gcc driver passes /export/build/gnu/gcc/build-x86_64-linux/gcc/collect-ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o pr28712.exe -r -L/export/build/gnu/gcc/build-x86_64-linux/gcc/32 -L/lib/../lib -L/usr/lib/../lib -L/export/build/gnu/gcc/build-x86_64-linux/gcc /tmp/ccLRsGQH.lto.o -lm to collect-ld. Only ia32 fails. -- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-17 13:35 --- I got # /export/build/gnu/gcc-32bit/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc-32bit/build-i686-linux/gcc/ /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -flto -r -nostdlib /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/pr28712.c -lm -o pr28712.exe -v /export/build/gnu/gcc-32bit/build-i686-linux/gcc/collect-ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o pr28712.exe -r -L/export/build/gnu/gcc-32bit/build-i686-linux/gcc /tmp/ccLvxKIY.o /tmp/ccpjReNk.o /tmp/ccBVusXG.o -lm /usr/local/bin/ld: cannot find -lm collect2: ld returned 1 exit status For some reason, gcc driver failed to pass -L/usr/lib to collect-ld. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702
[Bug lto/45702] [4.6 Regression] New LTO test failures
--- Comment #1 from rguenther at suse dot de 2010-09-17 12:56 --- Subject: Re: New: [4.6 Regression] New test failures On Fri, 17 Sep 2010, hjl dot tools at gmail dot com wrote: > On Linux/x86, revision 164357 gave > > FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -O (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -O3 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 -O (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 -O3 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 -O (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g3 -O3 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs -O (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs -O3 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs+ (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs+ -O (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs+ -O3 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs+1 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs+1 -O (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs+1 -O3 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs+3 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs+3 -O (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs+3 -O3 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs1 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs1 -O (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs1 -O3 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs3 (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs3 -O (test for excess errors) > FAIL: gcc.dg/debug/pr41893-1.c -gstabs3 -O3 (test for excess errors) > FAIL: gcc.dg/pr27898.c (test for excess errors) > FAIL: gcc.dg/pr28706.c (test for excess errors) > FAIL: gcc.dg/pr28712.c (test for excess errors) > FAIL: gcc.dg/pr30762-1.c (test for excess errors) > FAIL: gcc.dg/pr31529-1.c (test for excess errors) > FAIL: gcc.dg/pr34457-1.c (test for excess errors) > FAIL: gcc.dg/pr34668-1.c (test for excess errors) > FAIL: gcc.dg/pr34989-1.c (test for excess errors) > FAIL: gcc.dg/pr43557-1.c (test for excess errors) > > Revision 164355 is OK. What are the excess errors? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702