[Bug lto/45702] [4.6 Regression] New LTO test failures

[Bug lto/45702] [4.6 Regression] New LTO test failures

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at gcc dot gnu.org

--- Comment #18 from Rainer Orth <ro at gcc dot gnu.org> 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

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702

Richard Guenther <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> 2010-09-29 15:38:35 UTC ---
Mine.

[Bug lto/45702] [4.6 Regression] New LTO test failures

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702

--- Comment #20 from Richard Guenther <rguenth at gcc dot gnu.org> 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  <rguenther@suse.de>

    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

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702

--- Comment #21 from John David Anglin <danglin at gcc dot gnu.org> 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

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702

--- Comment #22 from rguenther at suse dot de <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 <danglin at gcc dot gnu.org> 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

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
                 CC|                            |jakub at gcc dot gnu.org

[Bug lto/45702] [4.6 Regression] New LTO test failures

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702

--- Comment #23 from Richard Guenther <rguenth at gcc dot gnu.org> 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  <rguenther@suse.de>

    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

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #24 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-04 11:11:03 UTC ---
Should be fixed now.

[Bug lto/45702] [4.6 Regression] New LTO test failures

[danglin at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P3

--- Comment #25 from John David Anglin <danglin at gcc dot gnu.org> 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

[dave at hiauly1 dot hia dot nrc dot ca]

------- 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

[rguenther at suse dot de]

------- 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

[danglin at gcc dot gnu dot org]

------- 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

[hjl dot tools at gmail dot com]

------- 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

[hjl dot tools at gmail dot com]

------- 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

[rguenther at suse dot de]

------- 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

[hjl dot tools at gmail dot com]

------- 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|0000-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

[hjl dot tools at gmail dot com]

------- 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

[rguenther at suse dot de]

------- 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

[jakub at gcc dot gnu dot org]

------- 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

[jakub at gcc dot gnu dot org]

------- 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

[rguenther at suse dot de]

------- 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
> 
> [hjl@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
> [hjl@gnu-6 gcc]$ 
> 
> Failed on ia32.
> 
> [hjl@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
> [hjl@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

[hjl dot tools at gmail dot com]

------- Comment #5 from hjl dot tools at gmail dot com  2010-09-17 13:52 -------
Works fine in 64bit with -m32

[hjl@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
[hjl@gnu-6 gcc]$ 

Failed on ia32.

[hjl@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
[hjl@gnu-6 gcc]$ 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45702

[Bug lto/45702] [4.6 Regression] New LTO test failures

[rguenther at suse dot de]

------- 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

[hjl dot tools at gmail dot com]

------- 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

[hjl dot tools at gmail dot com]

------- 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

[rguenther at suse dot de]

------- 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