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

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

[mikpe at it dot uu dot se]

Attempting to bootstrap gcc-4.6-20100828 on armv5tel-linux-gnueabi, after
applying the preliminary fixes for PR45444, fails with comparison failures
after stage 3:

make[3]: Leaving directory `/home/mikpe/objdir46'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/lto-cgraph.o differs
gcc/value-prof.o differs
gcc/expr.o differs
gcc/tree-ssa-loop-ivopts.o differs
gcc/lto-streamer-out.o differs
gcc/stor-layout.o differs
gcc/tree-ssa-loop-ivcanon.o differs
gcc/loop-iv.o differs
gcc/double-int.o differs
gcc/expmed.o differs
gcc/dbxout.o differs
gcc/tree.o differs
gcc/sreal.o differs
gcc/cfgloopanal.o differs
gcc/explow.o differs
libcpp/expr.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/mikpe/objdir46'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/mikpe/objdir46'
make: *** [bootstrap] Error 2

This looks almost identical to the failure in the presumed-fixed PR45162.

Configured with:
/home/mikpe/gcc-4.6-20100828/configure --enable-bootstrap --enable-shared
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --disable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--disable-sjlj-exceptions --with-arch=armv5te --with-tune=xscale
--build=armv5tel-brewer-linux-gnueabi
--with-gmp=/home/mikpe/pkgs/linux-armv5l/gmp-4.3.2
--with-mpfr=/home/mikpe/pkgs/linux-armv5l/mpfr-2.4.2
--with-mpc=/home/mikpe/pkgs/linux-armv5l/mpc-0.8.2 --disable-plugin
--disable-lto --disable-libmudflap


-- 
           Summary: [4.6 regression] ARM bootstrap failure: comparison
                    failures after stage 3
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mikpe at it dot uu dot se
  GCC host triplet: armv5tel-unknown-linux-gnueabi


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

[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

[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

[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|0000-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 #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:  01520004        cmpeq   r2, r4
   30:  3a000011        bcc     7c <normalize.isra.1+0x7c>
   34:  e5911000        ldr     r1, [r1]
-  38:  e0944004        adds    r4, r4, r4
+  38:  e1b04084        lsls    r4, r4, #1
   3c:  e0a55005        adc     r5, r5, r5
   40:  e1530005        cmp     r3, r5
   44:  01520004        cmpeq   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:      e1a0c33c        lsr     ip, ip, r3
      678:      e58d4018        str     r4, [sp, #24]
      67c:      e58d2020        str     r2, [sp, #32]
-     680:      e1cd21d8        ldrd    r2, [sp, #24]
-     684:      e0922002        adds    r2, r2, r2
-     688:      e58d5024        str     r5, [sp, #36]   ; 0x24
+     680:      e58d5024        str     r5, [sp, #36]   ; 0x24
+     684:      e1cd21d8        ldrd    r2, [sp, #24]
+     688:      e1b02082        lsls    r2, r2, #1
      68c:      e0a33003        adc     r3, r3, r3
-     690:      e1cd02d0        ldrd    r0, [sp, #32]
-     694:      e1822000        orr     r2, r2, r0
-     698:      e1833001        orr     r3, r3, r1
+     690:      e1cd42d0        ldrd    r4, [sp, #32]
+     694:      e1822004        orr     r2, r2, r4
+     698:      e1833005        orr     r3, r3, r5
      69c:      e58ab000        str     fp, [sl]
      6a0:      e58ac004        str     ip, [sl, #4]
      6a4:      e1c820f0        strd    r2, [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 #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:

00000000 <normalize>:
   0:   e1c020d0        ldrd    r2, [r0]
   4:   e0922002        adds    r2, r2, r2
   8:   e0a33003        adc     r3, r3, r3
   c:   e1c020f0        strd    r2, [r0]
  10:   e12fff1e        bx      lr
> stage2-gcc/xgcc -Bstage2-gcc -O2 -c sreal.c ; objdump -d sreal.o

sreal.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <normalize>:
   0:   e1c020d0        ldrd    r2, [r0]
   4:   e1b02082        lsls    r2, r2, #1
   8:   e0a33003        adc     r3, r3, r3
   c:   e1c020f0        strd    r2, [r0]
  10:   e12fff1e        bx      lr
> stage3-gcc/xgcc -Bstage3-gcc -O2 -c sreal.c ; objdump -d sreal.o

sreal.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <normalize>:
   0:   e1c020d0        ldrd    r2, [r0]
   4:   e1b02082        lsls    r2, r2, #1
   8:   e0a33003        adc     r3, r3, r3
   c:   e1c020f0        strd    r2, [r0]
  10:   e12fff1e        bx      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

[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

[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

[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.000000000 +0200
+++ dumps2/sreal.c.150r.expand  2010-09-19 17:20:36.000000000 +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

[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

[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

[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=gcc&view=rev&rev=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

[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

[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 #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.