Bug 50799 - [4.7 Regression] FAIL: gcc.dg/guality/pr43177.c
Summary: [4.7 Regression] FAIL: gcc.dg/guality/pr43177.c
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: debug (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: 4.7.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-19 17:48 UTC by H.J. Lu
Modified: 2011-10-20 22:52 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description H.J. Lu 2011-10-19 17:48:08 UTC
On Linux/ia32, revision 180194:

http://gcc.gnu.org/ml/gcc-cvs/2011-10/msg00790.html

caused:

FAIL: gcc.dg/guality/pr43177.c  -O2 -flto  line 15 x == 7
FAIL: gcc.dg/guality/pr43177.c  -O2 -flto  line 24 x == 7
FAIL: gcc.dg/guality/pr43177.c  -O2 -flto -flto-partition=none  line 15 x == 7
FAIL: gcc.dg/guality/pr43177.c  -O2 -flto -flto-partition=none  line 24 x == 7
Comment 1 Alexandre Oliva 2011-10-20 16:46:29 UTC
On it.  FWIW, I don't get these failures with rev 180136, with or without the patch, and I can't trigger them at 180194 either.  Can you get more info on what the failure is (say, debug dumps, asm output, whatever) so I can try to blind-debug it?  TIA,
Comment 2 H.J. Lu 2011-10-20 17:30:07 UTC
I saw them on Fedora 15 with gdb-7.3-43.fc15.x86_64.
Comment 3 Alexandre Oliva 2011-10-20 18:48:13 UTC
I'm on BLAG 140k/x86_64 (=~ Fedora 14).  The fact that the same compiler code works on a similar platform suggests to me that the problem is not in the compiler, but rather in the linker or the debugger.

I'm confused as to your report.  You wrote Linux/ia32, but it's a GDB for x86_64, which suggests a 64-x-32 build or a 32-bit bootstrap starting with a 64-bit -m32 compiler, or maybe a 32-bit bootstrap compiler on a x86_64 platform.  Anyhow, I tried all but the last of these options, to no avail, so I'll leave this alone unless I get more evidence that this is indeed a problem in the compiler, rather than some bug elsewhere that the patch happened to expose.

For the record, I've used:

gcc-4.5.1-4.fc14.x86_64 (with -m32)
glibc-2.14-4.i686
binutils-2.20.51.0.7-8.fc14.x86_64
gdb-7.2-51.fc14.x86_64

and ld.bfd is the linker used by the bootstrap and the built compilers.
Comment 4 Alexandre Oliva 2011-10-20 19:15:51 UTC
Just tried with ld.gold instead, still no failure.
Comment 5 H.J. Lu 2011-10-20 19:24:55 UTC
You should try gdb 7.3 to see if it makes a difference.
Comment 6 Alexandre Oliva 2011-10-20 19:57:41 UTC
What kind of error are you getting from gdb 7.3?  Since 7.2 is getting the correct info, that's the bug report that ought to be submitted to GDB.
Comment 7 H.J. Lu 2011-10-20 21:04:59 UTC
(In reply to comment #6)
> What kind of error are you getting from gdb 7.3?  Since 7.2 is getting the
> correct info, that's the bug report that ought to be submitted to GDB.

My understanding is most of guality tests are skipped with older
GDB, like

# make check-gcc RUNTESTFLAGS="guality.exp=pr43177.c"
...
# of expected passes		20
# of unsupported tests		28

Is gcc.dg/guality/pr43177.c tested with GDB 7.2?
Comment 8 Alexandre Oliva 2011-10-20 21:45:42 UTC
Err, that doesn't seem to tell what errors you're getting from gdb.  I know older GDB might cause tests to be skipped, but that's not the case here.  I'm getting the expected 48 passes and nothing else from make check-gcc guality.exp=pr43177.c
Comment 9 H.J. Lu 2011-10-20 22:41:19 UTC
(In reply to comment #6)
> What kind of error are you getting from gdb 7.3?  Since 7.2 is getting the
> correct info, that's the bug report that ought to be submitted to GDB.

I got

Breakpoint 1, baz (x=<optimized out>) at /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/guality/pr43177.c:24^M
24        bar (l);/* { dg-final { gdb-test 24 "x" "7" } } */^M
$1 = <optimized out>^M
$2 = 7^M 
<optimized out> != 7

It could be a GDB regression.
Comment 10 Alexandre Oliva 2011-10-20 22:52:54 UTC
Yep.  That, or some other difference in the compiler's assembly output, that I asked for in comment 1.