[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #28 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-03 
16:26:46 UTC ---
FIXED I assume.

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[bernds at gcc dot gnu.org]

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

--- Comment #27 from Bernd Schmidt bernds at gcc dot gnu.org 2010-10-11 
19:39:41 UTC ---
Author: bernds
Date: Mon Oct 11 19:39:37 2010
New Revision: 165329

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165329
Log:
PR bootstrap/45445
* ira-lives.c (mark_pseudo_reg_live, mark_pseudo_reg_dead): New
static functions.
(mark_ref_live, mark_ref_dead): Use them.
(make_pseudo_conflict): New arg ORIG_DREG.  All callers changed.
Save the original reg, and use the new functions.
(check_and_make_def_use_conflict): New arg ORIG_DREG.  All callers
changed.
(check_and_make_def_conflict): Save the original reg.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-lives.c

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[laurent at guerby dot net]

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

--- Comment #25 from Laurent GUERBY laurent at guerby dot net 2010-09-29 
07:08:58 UTC ---
On armv5tel-unknown-linux-gnueabi with this patch at r164682 I still hit
PR44970 so bootstrap failed.

Mikael what made your bootstrap succeed?

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu.se]

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

--- Comment #26 from Mikael Pettersson mikpe at it dot uu.se 2010-09-29 
11:07:32 UTC ---
(In reply to comment #25)
 On armv5tel-unknown-linux-gnueabi with this patch at r164682 I still hit
 PR44970 so bootstrap failed.
 
 Mikael what made your bootstrap succeed?

Notice that I went back to the original broken rev, 162418.  Since I've not
been able to bootstrap any post-r162417 4.6 before, I didn't want to
contaminate this test by exposing it to some unknown set of later
bootstrap-breaking bugs.

The first weekly snapshot after that one, 4.6-20100724 (r162503), bootstraps
fine for me with (a) Bernd's proposed fix for this PR (essential), (b) r162784
to fix PR45067 (essential), and (c) Joern's proposed but still unapplied patch
for PR44335 (java FE build fix).  It's currently running the test suite.

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu.se]

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

--- Comment #24 from Mikael Pettersson mikpe at it dot uu.se 2010-09-28 
20:50:01 UTC ---
(In reply to comment #23)
 Created attachment 21902 [details]
 A patch which should fix it
 
 Please verify whether this patch fixes it.

I did a C-only bootstrap of 4.6 r162418 + this patch and it succeeded with no
comparison failures.  The resulting compiler also correctly compiled the test
case I posted.

Thanks.

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[bernds at gcc dot gnu.org]

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

--- Comment #22 from Bernd Schmidt bernds at gcc dot gnu.org 2010-09-27 
12:45:36 UTC ---
Thanks, that's very well done.  I've investigated a bit, and it seems the
sequence

  mark_pseudo_regno_live (REGNO (reg));
  mark_pseudo_regno_live (REGNO (dreg));
  mark_pseudo_regno_dead (REGNO (reg));
  mark_pseudo_regno_dead (REGNO (dreg));

in make_pseudo_conflict is breaking lifetimes of subwords of one of the DImode
registers.  Not entirely sure yet how to fix it, but I'll think of something.

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[bernds at gcc dot gnu dot org]

--- Comment #19 from bernds at gcc dot gnu dot org  2010-09-21 11:12 ---
Can you provide a .i file for which this is reproducible with a cross compiler?

Before/after -fdump-rtl-ira dumps and assembly files could also be helpful.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #20 from mikpe at it dot uu dot se  2010-09-21 11:30 ---
(In reply to comment #19)
 Can you provide a .i file for which this is reproducible with a cross 
 compiler?
 
 Before/after -fdump-rtl-ira dumps and assembly files could also be helpful.

I'm leaving in a couple of minutes on work-related travelling.  I'll resume my
attempts to convert the miscompiled code to a minimized and standalone test
case on thursday.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #17 from mikpe at it dot uu dot se  2010-09-20 12:40 ---
expmed.c:expand_shift () is miscompiled: breaking that function out to a
separate source file, compiling it with stage1/xgcc, and relinking stage2/cc1 I
get 'lsls', compiling it with the bootstrap gcc and relinking stage2/cc1 I get
'adds'.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #18 from mikpe at it dot uu dot se  2010-09-20 22:05 ---
It's the 17 line if-for-return block headed by

  /* Check whether its cheaper to implement a left shift by a constant
 bit count by a sequence of additions.  */

that gets miscompiled by stage1, which makes sense given the observed effects.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #14 from mikpe at it dot uu dot se  2010-09-19 15:30 ---
On the trivial sreal.c test case the dumps (-fdump-rtl-all -fdump-tree-all)
from stage1 and stage2 start to diverge at `150r.expand':

diff -ru dumps1/sreal.c.150r.expand dumps2/sreal.c.150r.expand
--- dumps1/sreal.c.150r.expand  2010-09-19 17:20:07.0 +0200
+++ dumps2/sreal.c.150r.expand  2010-09-19 17:20:36.0 +0200
@@ -26,8 +26,8 @@

 (insn 7 6 8 3 (parallel [
 (set (reg:DI 137)
-(plus:DI (reg:DI 136)
-(reg:DI 136)))
+(ashift:DI (reg:DI 136)
+(const_int 1 [0x1])))
 (clobber (reg:CC 24 cc))
 ]) sreal.c:3 -1
  (nil))

The immediately preceeding dump (149t.optimized) is as follows for both stages:

;; Function normalize (normalize)

normalize (long long unsigned int * sreal_sig)
{
  long long unsigned int D.2004;
  long long unsigned int D.2003;

bb 2:
  D.2003_2 = *sreal_sig_1(D);
  D.2004_3 = D.2003_2  1;
  *sreal_sig_1(D) = D.2004_3;
  return;

}

I'll try mixing stage1 and stage2 .o files next.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #15 from mikpe at it dot uu dot se  2010-09-19 16:29 ---
The code generation difference originates from `expmed.o'.  Using stage1's
expmed.o with stage2's other .o files I get 'adds', using stage2's expmed.o
with stage1's other .o files I get 'lsls'.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[laurent at guerby dot net]

--- Comment #16 from laurent at guerby dot net  2010-09-19 16:54 ---
expmed.c:make_tree has some non deterministic calls:

tree
make_tree (tree type, rtx x)
{
...
case PLUS:
  return fold_build2 (PLUS_EXPR, type, make_tree (type, XEXP (x, 0)),
  make_tree (type, XEXP (x, 1)));
...


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[laurent at guerby dot net]

--- Comment #11 from laurent at guerby dot net  2010-09-16 11:49 ---
With  --with-arch=armv5te --with-tune=xscale I get the comparison failure.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[bernds at gcc dot gnu dot org]

--- Comment #12 from bernds at gcc dot gnu dot org  2010-09-16 13:50 ---
(In reply to comment #6)
 So stage1 chooses adds but stage2 and stage3 choose lsls for  of the lower
 half of a long long.  Since the behaviour of a stageN xgcc depends on both the
 gcc source code and the compiler used to build it, I have to suspect a source
 code ambiguity (e.g. evaluation order dependence) that the bootstrap compiler
 (gcc-4.4.4 in my case) resolves differently from post-r162417 4.6.

I think it's likely there really is a miscompilation.  I've not been able to
get very far trying to set up a native compiler to run on qemu, so it would
help if you could try to narrow it down a bit further.

IIUC, stage1 and stage2 produce different output for some output files, such as
expr.o.  You could try to copy object files from stage1 to stage2, then rebuild
the stage2 compiler with these objects, until these differences go away.  In
that way, you can determine which file is being miscompiled by stage1.  The
next step would be to find code generation differences for that file between
r162417 and r162418.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[rearnsha at gcc dot gnu dot org]

--- Comment #13 from rearnsha at gcc dot gnu dot org  2010-09-16 16:54 
---
(In reply to comment #12)
 I think it's likely there really is a miscompilation.  I've not been able to
 get very far trying to set up a native compiler to run on qemu, so it would
 help if you could try to narrow it down a bit further.
 
 IIUC, stage1 and stage2 produce different output for some output files, such 
 as
 expr.o.  You could try to copy object files from stage1 to stage2, then 
 rebuild
 the stage2 compiler with these objects, until these differences go away.  In
 that way, you can determine which file is being miscompiled by stage1.  The
 next step would be to find code generation differences for that file between
 r162417 and r162418.
 

You might also narrow down the source of the problem by comparing the dump
files from using the two compilers -- the time at which the dumps start to
diverge will be a strong indicator of the point at which the problem was
introduced.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[laurent at guerby dot net]

--- Comment #8 from laurent at guerby dot net  2010-09-14 19:19 ---
With 4.4.2 as base on gcc57 (and your PR45444 patch) I don't see the comparison
failure:

http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg01282.html


-- 

laurent at guerby dot net changed:

   What|Removed |Added

 CC||laurent at guerby dot net


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #9 from mikpe at it dot uu dot se  2010-09-14 19:40 ---
(In reply to comment #8)
 With 4.4.2 as base on gcc57 (and your PR45444 patch) I don't see the 
 comparison
 failure:
 
 http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg01282.html

Please try --with-arch=armv5te --with-tune=xscale in the configure options.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[laurent at guerby dot net]

--- Comment #10 from laurent at guerby dot net  2010-09-14 20:04 ---
Ok will do.

Note: arm.c:arm_reload_in_hi() seems to have a few non deterministic calls to
gen_rtx_*, eg:

  emit_insn (gen_zero_extendqisi2 (gen_rtx_SUBREG (SImode, operands[0], 0),
   gen_rtx_MEM (QImode,
plus_constant (base,
   offset + 1;
  ... (and a few other calls like that)

Same for arm.c:arm_reload_out_hi()

I don't know if this is normal coding style.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #7 from mikpe at it dot uu dot se  2010-09-09 10:21 ---
It's not a stage2/stage3 debug difference as far as I can tell.  I've
recompiled every differing .o file with the stage 1/2/3 xgccs -fcompare-debug
without complaints.

The test case showing the different code generation is trivial (this is in the
objdir for a native bootstrap of r163951):

 cat sreal.c
void normalize(unsigned long long *sreal_sig)
{
*sreal_sig = 1;
}
 stage1-gcc/xgcc -Bstage1-gcc -O2 -c sreal.c; objdump -d sreal.o

sreal.o: file format elf32-littlearm


Disassembly of section .text:

 normalize:
   0:   e1c020d0ldrdr2, [r0]
   4:   e0922002addsr2, r2, r2
   8:   e0a33003adc r3, r3, r3
   c:   e1c020f0strdr2, [r0]
  10:   e12fff1ebx  lr
 stage2-gcc/xgcc -Bstage2-gcc -O2 -c sreal.c ; objdump -d sreal.o

sreal.o: file format elf32-littlearm


Disassembly of section .text:

 normalize:
   0:   e1c020d0ldrdr2, [r0]
   4:   e1b02082lslsr2, r2, #1
   8:   e0a33003adc r3, r3, r3
   c:   e1c020f0strdr2, [r0]
  10:   e12fff1ebx  lr
 stage3-gcc/xgcc -Bstage3-gcc -O2 -c sreal.c ; objdump -d sreal.o

sreal.o: file format elf32-littlearm


Disassembly of section .text:

 normalize:
   0:   e1c020d0ldrdr2, [r0]
   4:   e1b02082lslsr2, r2, #1
   8:   e0a33003adc r3, r3, r3
   c:   e1c020f0strdr2, [r0]
  10:   e12fff1ebx  lr

So stage1 chooses adds but stage2 and stage3 choose lsls for  of the lower
half of a long long.  Since the behaviour of a stageN xgcc depends on both the
gcc source code and the compiler used to build it, I have to suspect a source
code ambiguity (e.g. evaluation order dependence) that the bootstrap compiler
(gcc-4.4.4 in my case) resolves differently from post-r162417 4.6.

I've so far not been able to reproduce this difference in a cross from i686;
those cross compilers always seem to choose the adds form regardless of the
version of gcc I'm building with.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #6 from mikpe at it dot uu dot se  2010-09-08 12:24 ---
The smallest .o file that differs between stage2 and stage3 is sreal.o. Diffing
the objdump -d output shows:

@@ -1,5 +1,5 @@

-stage2-gcc/sreal.o: file format elf32-littlearm
+stage3-gcc/sreal.o: file format elf32-littlearm


 Disassembly of section .text:
@@ -19,7 +19,7 @@
   2c:  01520004cmpeq   r2, r4
   30:  3a11bcc 7c normalize.isra.1+0x7c
   34:  e5911000ldr r1, [r1]
-  38:  e0944004addsr4, r4, r4
+  38:  e1b04084lslsr4, r4, #1
   3c:  e0a55005adc r5, r5, r5
   40:  e1530005cmp r3, r5
   44:  01520004cmpeq   r2, r4

That is, a single adds became an lsls instead.

cfgloopanal.o and tree-ssa-loop-ivcanon.o show the exact same one-instruction
adds-became-lsls difference.

double-int.o has more elaborate differences:

@@ -1,5 +1,5 @@

-stage2-gcc/double-int.o: file format elf32-littlearm
+stage3-gcc/double-int.o: file format elf32-littlearm


 Disassembly of section .text:
@@ -427,13 +427,13 @@
  674:  e1a0c33clsr ip, ip, r3
  678:  e58d4018str r4, [sp, #24]
  67c:  e58d2020str r2, [sp, #32]
- 680:  e1cd21d8ldrdr2, [sp, #24]
- 684:  e0922002addsr2, r2, r2
- 688:  e58d5024str r5, [sp, #36]   ; 0x24
+ 680:  e58d5024str r5, [sp, #36]   ; 0x24
+ 684:  e1cd21d8ldrdr2, [sp, #24]
+ 688:  e1b02082lslsr2, r2, #1
  68c:  e0a33003adc r3, r3, r3
- 690:  e1cd02d0ldrdr0, [sp, #32]
- 694:  e1822000orr r2, r2, r0
- 698:  e1833001orr r3, r3, r1
+ 690:  e1cd42d0ldrdr4, [sp, #32]
+ 694:  e1822004orr r2, r2, r4
+ 698:  e1833005orr r3, r3, r5
  69c:  e58ab000str fp, [sl]
  6a0:  e58ac004str ip, [sl, #4]
  6a4:  e1c820f0strdr2, [r8]

I'll try to extract a test case from one of these.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #3 from mikpe at it dot uu dot se  2010-09-07 14:25 ---
This set of bootstrap comparison failures were introduced by r162418:
http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00772.html

It's been a pain to bisect because pretty much every week between then and now
there's been some other bootstrap-breaking bug masking this one.

I'm currently checking if latest trunk (r163951) is still broken.


-- 

mikpe at it dot uu dot se changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu dot
   ||org


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[ramana at gcc dot gnu dot org]

--- Comment #4 from ramana at gcc dot gnu dot org  2010-09-07 16:42 ---
Confirmed based on comment #2


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-09-07 16:42:14
   date||


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #5 from mikpe at it dot uu dot se  2010-09-07 22:26 ---
(In reply to comment #3)
 I'm currently checking if latest trunk (r163951) is still broken.

It is.  I'll try to come up with a cross-compiler friendly test case tomorrow.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[mikpe at it dot uu dot se]

--- Comment #2 from mikpe at it dot uu dot se  2010-09-02 20:55 ---
(In reply to comment #1)
 With r163667 and fixes for PR45444 applied I don't see issues with a v7-a
 bootstrap. Can we see if a later version works for you ? 

With r163777 and the proposed PR45444 fix applied I still get the same
bootstrap comparison failures after stage3 as before.

Your v7-a build probably triggers different code generation paths than my
armv5te with xscale tuning build.


-- 


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[ramana at gcc dot gnu dot org]

--- Comment #1 from ramana at gcc dot gnu dot org  2010-09-01 14:54 ---
With r163667 and fixes for PR45444 applied I don't see issues with a v7-a
bootstrap. Can we see if a later version works for you ? 

Ramana


-- 

ramana at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


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

[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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