Bug 44255 - [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
Summary: [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: 4.6.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 44270 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-05-23 15:43 UTC by Mikael Pettersson
Modified: 2010-05-31 07:20 UTC (History)
3 users (show)

See Also:
Host: sparc64-unknown-linux-gnu, armv5tel-unknown-linux-gnueabi
Target: sparc64-unknown-linux-gnu, armv5tel-unknown-linux-gnueabi
Build: sparc64-unknown-linux-gnu, armv5tel-unknown-linux-gnueabi
Known to work:
Known to fail:
Last reconfirmed:


Attachments
preprocessed source for libiberty/cp-demangle.c (27.84 KB, text/plain)
2010-05-27 21:35 UTC, Mikael Pettersson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mikael Pettersson 2010-05-23 15:43:32 UTC
4.6-20100515 (r159445) bootstrapped fine on my sparc64-linux machine.
4.6-20100522 (r159746) gets a bootstrap comparison failure in stage 3:

...
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
libiberty/cp-demangle.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/mnt/scratch/objdir46'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir46'
make: *** [bootstrap] Error 2

Configuration parameters:
/mnt/scratch/gcc-4.6-20100522/configure --with-gmp=/home/mikpe/pkgs/linux-sparc64/gmp-4.3.2 --with-mpfr=/home/mikpe/pkgs/linux-sparc64/mpfr-2.4.2 --with-mpc=/home/mikpe/pkgs/linux-sparc64/mpc-0.8.1 --with-cpu=v8 --enable-multilib --disable-plugin --disable-lto --disable-nls --enable-threads=posix --enable-checking=release --disable-libmudflap --enable-languages=c

I'll try to bisect it.
Comment 1 Mikael Pettersson 2010-05-23 21:09:35 UTC
The exact same bootstrap comparison failure now also showed up in my attempt to build gcc-4.6-20100522 on armv5tel-unknown-linux-gnueabi. And like sparc64 the previous 4.6 weekly snapshot bootstrapped fine.
Comment 2 Mikael Pettersson 2010-05-24 09:31:01 UTC
Bisection identified r159600 as the source of the failure on sparc64:

Author: rsandifo
Date: Wed May 19 21:08:53 2010
New Revision: 159600

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159600
Log:
gcc/
	* combine.c (propagate_for_debug): Call make_compound_operation
	on the source value.
	(try_combine): When implementing a split chosen by find_split_point,
	either copy i2src or set it to null.  Assert that i2src is not null
	before substituting into CALL_INSN_FUNCTION_USAGE.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/combine.c

The corresponding gcc-patches thread started here:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01296.html

My ARM box is currently busy running another test, but as soon as that finishes I'll check if r159600 is also responsible for the ARM bootstrap failure.
Comment 3 Iain Sandoe 2010-05-24 11:46:07 UTC
most likely this is a duplicate of:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229

and potentially an LE/BE issue given that it's not reported on *x86*
Comment 4 Mikael Pettersson 2010-05-24 16:16:21 UTC
(In reply to comment #3)
> most likely this is a duplicate of:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229
> 
> and potentially an LE/BE issue given that it's not reported on *x86*

However:
1. I see the failure on both BE (sparc64) and LE (armv5tel).
2. Both BE (powerpc64-linux) and LE (x86) don't see the failure.

So I doubt it's an endianess issue.

Comment 5 Mikael Pettersson 2010-05-24 16:21:56 UTC
Comparing stage2-libiberty/cp-demangle.o with stage3-libiberty/cp-demangle.o shows that one instruction has had it's source operands swapped:

> objdump -d stage2-libiberty/cp-demangle.o > a
> objdump -d stage3-libiberty/cp-demangle.o > b
> diff -u a b
--- a   2010-05-24 17:59:49.000000000 +0200
+++ b   2010-05-24 17:59:54.000000000 +0200
@@ -1,5 +1,5 @@
 
-stage2-libiberty/cp-demangle.o:     file format elf32-sparc
+stage3-libiberty/cp-demangle.o:     file format elf32-sparc
 
 
 Disassembly of section .text:
@@ -4702,7 +4702,7 @@
     5078:      89 29 20 04     sll  %g4, 4, %g4
     507c:      84 00 80 04     add  %g2, %g4, %g2
     5080:      84 00 b8 6c     add  %g2, -1940, %g2
-    5084:      84 80 80 03     addcc  %g2, %g3, %g2
+    5084:      84 80 c0 02     addcc  %g3, %g2, %g2
     5088:      22 80 02 11     be,a   58cc <cplus_demangle_type+0xa20>
     508c:      c4 00 a0 04     ld  [ %g2 + 4 ], %g2
     5090:      c6 06 20 14     ld  [ %i0 + 0x14 ], %g3

Now, the code is still correct, but gcc shouldn't arbitrarily change it's mind like this in stage3. Hence I suspect r159600 introduces some non-determinism, or exposes latent non-determinism.
Comment 6 Mikael Pettersson 2010-05-24 22:24:19 UTC
The stage 3 comparison failure on ARM is as follows:
...
Bootstrap comparison failure!
libiberty/pic/cp-demangle.o differs

Comparing the disassembly listings of prev-libiberty/pic/cp-demangle.o and libiberty/pic/cp-demangle.o yields:

@@ -1,5 +1,5 @@
 
-prev-libiberty/pic/cp-demangle.o:     file format elf32-littlearm
+libiberty/pic/cp-demangle.o:     file format elf32-littlearm
 
 
 Disassembly of section .text:
@@ -4751,12 +4751,12 @@
     4954:      e58d0004        str     r0, [sp, #4]
     4958:      eaffffe7        b       48fc <cplus_demangle_type+0x21c>
     495c:      e3a01014        mov     r1, #20 ; 0x14
-    4960:      e0010193        mul     r1, r3, r1
-    4964:      e59f38e8        ldr     r3, [pc, #2280] ; 5254 <cplus_demangle_type+0xb74>
-    4968:      e2411e79        sub     r1, r1, #1936   ; 0x790
-    496c:      e2411004        sub     r1, r1, #4      ; 0x4
-    4970:      e7923003        ldr     r3, [r2, r3]
-    4974:      e0913003        adds    r3, r1, r3
+    4960:      e0030391        mul     r3, r1, r3
+    4964:      e59f18e8        ldr     r1, [pc, #2280] ; 5254 <cplus_demangle_type+0xb74>
+    4968:      e2433e79        sub     r3, r3, #1936   ; 0x790
+    496c:      e2433004        sub     r3, r3, #4      ; 0x4
+    4970:      e7922001        ldr     r2, [r2, r1]
+    4974:      e0923003        adds    r3, r2, r3
     4978:      0a000215        beq     51d4 <cplus_demangle_type+0xaf4>
     497c:      e5942014        ldr     r2, [r4, #20]
     4980:      e5941018        ldr     r1, [r4, #24]

So it's not just two swapped source operands in an arithmetic instruction as on sparc, but also different (still valid) register assignment.
Comment 7 Iain Sandoe 2010-05-25 07:38:31 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > most likely this is a duplicate of:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229

> 1. I see the failure on both BE (sparc64) and LE (armv5tel).
> 2. Both BE (powerpc64-linux) and LE (x86) don't see the failure.

No failure on powerpc64-apple-darwin9 either.
Comment 8 Jakub Jelinek 2010-05-25 07:57:53 UTC
If cp-demangle.c fails to compile even with -fcompare-debug switch added, please
attach preprocessed source for it from sparc64 and/or arm and mention the exact command line switches used to compile it, so it can be reproduced with a cross-compiler.  Thanks.
Comment 9 Richard Biener 2010-05-25 13:27:26 UTC
*** Bug 44270 has been marked as a duplicate of this bug. ***
Comment 10 Mikael Pettersson 2010-05-26 15:16:59 UTC
(In reply to comment #2)
> My ARM box is currently busy running another test, but as soon as that finishes
> I'll check if r159600 is also responsible for the ARM bootstrap failure.

It is, r159599 bootstraps on ARM, r159600 does not.

Comment 11 Mikael Pettersson 2010-05-27 21:35:51 UTC
Created attachment 20763 [details]
preprocessed source for libiberty/cp-demangle.c

Here's the preprocessed source for libiberty/cp-demangle.c as generated by gcc-4.6-20100522 on sparc64-unknown-linux.  The same 4.6 snapshot built on x86 as a cross to sparc64-unknown-linux also fails with -m32 -g -fcompare-debug -O2:

> sparc64-unknown-linux-gcc -m32 -g -fcompare-debug -O2 -c cp-demangle.i
sparc64-unknown-linux-gcc: cp-demangle.i: -fcompare-debug failure

If you compile cp-demangle.i to .o first with -g0 and then with -g and compare the objdump -d output from those two object files, you'll find a single instruction difference at or near address 0x5080 in function cplus_demangle_type ().
Comment 12 Jakub Jelinek 2010-05-27 22:09:01 UTC
Subject: Bug 44255

Author: jakub
Date: Thu May 27 22:08:41 2010
New Revision: 159952

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159952
Log:
	PR bootstrap/44255
	* combine.c (struct rtx_subst_pair): Define unconditionally.
	(propagate_for_debug_subst): Likewise.  If not AUTO_INC_DEC,
	copy_rtx pair->to instead of cleanup_auto_inc_dec it.
	Call make_compound_operation on pair->to.
	(propagate_for_debug): Don't call make_compound_operation here.
	Always use simplify_replace_fn_rtx.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/combine.c

Comment 13 Mikael Pettersson 2010-05-28 16:02:28 UTC
Jakub's patch fixed 4.6 bootstrap on my sparc64 machine.  My ARM is testing other branches currently, but I should have 4.6 bootstrap results for it on Sunday or Monday, at which time I'll close this PR if things went well.
Comment 14 Mikael Pettersson 2010-05-31 07:20:18 UTC
The bootstrap comparison failure is gone on armv5tel-unknown-linux-gnueabi with gcc-4.6-20100529.  Thus closing as fixed.