------- Comment #5 from mikpe at it dot uu dot se 2010-05-24 16:21 ------- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255