[Bug bootstrap/43399] New: [4.5 Regression] bootstrap failure in stage1

[Bug bootstrap/43399] New: [4.5 Regression] bootstrap failure in stage1

[robertcnelson at gmail dot com]

current trunk is failing bootstrap in stage 1 on Cortex-A8 (armv7l target)
First caught it svn 157489.  Started bisection yesterday between 157445 &
157489. First bad commit is: 157476.

System is running Debian Testing(Squeeze)

Error:
/opt/trunk/objdir/./gcc/xgcc -B/opt/trunk/objdir/./gcc/
-B/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/bin/
-B/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/lib/ -isystem
/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/include -isystem
/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/sys-include    -g -O2 -O2 
-g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC
-Wno-missing-prototypes -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc -I/opt/trunk/libgcc
-I/opt/trunk/libgcc/. -I/opt/trunk/libgcc/../gcc -I/opt/trunk/libgcc/../include
  -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/opt/trunk/libgcc/../gcc/libgcc2.c \
          -fvisibility=hidden -DHIDE_EXPORTS
/opt/trunk/libgcc/../gcc/libgcc2.c: In function '__muldi3':
/opt/trunk/libgcc/../gcc/libgcc2.c:562:1: internal compiler error: in
adjust_mems, at var-tracking.c:789
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [_muldi3.o] Error 1
make[3]: Leaving directory
`/var/builds/opt/trunk/objdir/armv7l-unknown-linux-gnueabi/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/var/builds/opt/trunk/objdir'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/var/builds/opt/trunk/objdir'
make: *** [bootstrap] Error 2
gcc_build: error: Could not bootstrap the compiler

Build Logs:
http://rcn-ee.homeip.net:81/dl/gcc/SVN-157476-trunk-c-armv7l-256-ERROR/

I'll need to rebuild that svn id to provide more test info, as i delete the old
build when building a new checkout..

Note a similar commit went into gcc-4.4 at : 157487 (var-tracking.c) so gcc-4.4
might be broken too..


-- 
           Summary: [4.5 Regression] bootstrap failure in stage1
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: robertcnelson at gmail dot com
GCC target triplet: armv7l-unknown-linux-gnueabi


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

[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1

[jakub at gcc dot gnu dot org]

------- Comment #1 from jakub at gcc dot gnu dot org  2010-03-17 12:56 -------
Please provide preprocessed source.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |WAITING
   Target Milestone|---                         |4.5.0


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

[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1

[jakub at gcc dot gnu dot org]

------- Comment #2 from jakub at gcc dot gnu dot org  2010-03-17 13:51 -------
*** Bug 43400 has been marked as a duplicate of this bug. ***


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bero at arklinux dot org


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

[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1

[robertcnelson at gmail dot com]

------- Comment #3 from robertcnelson at gmail dot com  2010-03-17 14:04 -------
Rebuilding 157476, will take a couple hours to hit that error..

System: gcc -v

voodoo@beagle-256mb-1:~$ gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.2-9'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --enable-linker-build-id --with-system-zlib
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--disable-sjlj-exceptions --enable-checking=release --build=arm-linux-gnueabi
--host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.4.3 20100108 (prerelease) (Debian 4.4.2-9) 


-- 


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

[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1

[robertcnelson at gmail dot com]

------- Comment #4 from robertcnelson at gmail dot com  2010-03-17 15:42 -------
Here here is the preprocessed source.

http://rcn-ee.homeip.net:81/dl/gcc/SVN-157476-trunk-c-armv7l-256-bug43399/save-temps.log

http://rcn-ee.homeip.net:81/dl/gcc/SVN-157476-trunk-c-armv7l-256-bug43399/libgcc2.i

Results from running with:

/opt/trunk/objdir/./gcc/xgcc -v -save-temps -B/opt/trunk/objdir/./gcc/
-B/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/bin/
-B/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/lib/ -isystem
/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/include -isystem
/opt/install-gcc-trunk/armv7l-unknown-linux-gnueabi/sys-include    -g -O2 -O2 
-g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC
-Wno-missing-prototypes -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc -I/opt/trunk/libgcc
-I/opt/trunk/libgcc/. -I/opt/trunk/libgcc/../gcc -I/opt/trunk/libgcc/../include
  -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/opt/trunk/libgcc/../gcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS^C


-- 


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

[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1

[jakub at gcc dot gnu dot org]

------- Comment #5 from jakub at gcc dot gnu dot org  2010-03-17 21:44 -------
Argh, seems ARM is very badly abusing PRE_DEC:
(insn/f 72 41 73 2 /opt/trunk/libgcc/../gcc/libgcc2.c:553 (parallel [
            (set (mem/c:BLK (pre_dec:BLK (reg/f:SI 13 sp)) [6 A8])
                (unspec:BLK [
                        (reg:SI 4 r4)
                    ] 2))
        ]) 326 {*push_multi} (expr_list:REG_DEAD (reg:SI 4 r4)
        (expr_list:REG_FRAME_RELATED_EXPR (sequence [
                    (set/f (reg/f:SI 13 sp)
                        (plus:SI (reg/f:SI 13 sp)
                            (const_int -4 [0xfffffffffffffffc])))
                    (set/f (mem/c:SI (reg/f:SI 13 sp) [6 S4 A32])
                        (reg:SI 4 r4))
                ])
            (nil))))
This violates PRE_DEC documentation in 2 ways:
1) PRE_DEC's mode is not a machine mode for pointers
2) the decrement size is not equal to the size of the mode (as BLKmode size is
0).

@item (pre_dec:@var{m} @var{x})
Represents the side effect of decrementing @var{x} by a standard
amount and represents also the value that @var{x} has after being
decremented.  @var{x} must be a @code{reg} or @code{mem}, but most
machines allow only a @code{reg}.  @var{m} must be the machine mode
for pointers on the machine in use.  The amount @var{x} is decremented
by is the length in bytes of the machine mode of the containing memory
reference of which this expression serves as the address.

I think var-tracking isn't the only one which can be significantly confused by
this (what should it do?), so can DSE, cselib, ...

I'd say the best fix would be actually stop emitting this bogosity by the ARM
backend.  Either you can look at e.g. what s390 does for its load/store
multiple patterns, or even just use PRE_MODIFY instead of PRE_DEC and make the
stack pointer adjustment there explicit and obvious.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ramana at gcc dot gnu dot
                   |                            |org


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

[Bug target/43399] [4.5 Regression] bootstrap failure in stage1

[ramana at gcc dot gnu dot org]

------- Comment #6 from ramana at gcc dot gnu dot org  2010-03-17 22:43 -------
As per Comment #4 and based on conversations on IRC, this is certainly a target
bug . I have verified that this very testcase attached also has the same effect
on the arm-eabi target ( a simple -g -O2 is enough to trigger the ICE) , the
canonical primary platform for the ARM port as well.

Could the release managers consider re-priotizing this bug upwards for the ARM
port ? 

cheers
Ramana


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
          Component|bootstrap                   |target
     Ever Confirmed|0                           |1
 GCC target triplet|armv7l-unknown-linux-gnueabi|armv7l-unknown-linux-
                   |                            |gnueabi, arm-eabi
      Known to fail|                            |4.5.0
   Last reconfirmed|0000-00-00 00:00:00         |2010-03-17 22:43:30
               date|                            |


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

[Bug target/43399] [4.5 Regression] bootstrap failure in stage1

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1

[rearnsha at gcc dot gnu dot org]

-- 

rearnsha at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rearnsha at gcc dot gnu dot
                   |                            |org
          Component|target                      |bootstrap
           Priority|P1                          |P3


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

[Bug target/43399] [4.5 Regression] bootstrap failure in stage1

[rearnsha at gcc dot gnu dot org]

-- 

rearnsha at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|bootstrap                   |target
           Priority|P3                          |P1


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

[Bug target/43399] [4.5 Regression] bootstrap failure in stage1

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2010-03-18 07:16 -------
BTW, if the PRE_MODIFY representation doesn't work well, I'd say just using a
PARALLEL with what the insn really does and checking that in the match_parallel
predicate probably wouldn't clash with anything else.  If it would, you'd need
to insert one UNSPEC somewhere.
The comments say that currently the pattern looks like:
       (parallel [
           (set (mem:BLK (pre_dec:BLK (reg:SI sp)))
                (unspec:BLK [(reg:SI r4)] UNSPEC_PUSH_MULT))
           (use (reg:SI 11 fp))
           (use (reg:SI 12 ip))
           (use (reg:SI 14 lr))
           (use (reg:SI 15 pc))
        ])
with the REG_FRAME_RELATED_EXPR:
      (sequence [
           (set (reg:SI sp) (plus:SI (reg:SI sp) (const_int -20)))
           (set (mem:SI (reg:SI sp)) (reg:SI r4))
           (set (mem:SI (plus:SI (reg:SI sp) (const_int 4))) (reg:SI fp))
           (set (mem:SI (plus:SI (reg:SI sp) (const_int 8))) (reg:SI ip))
           (set (mem:SI (plus:SI (reg:SI sp) (const_int 12))) (reg:SI lr))
        ])
So, would a parallel like:
       (parallel [
           (set (mem:SI (plus:SI (reg:SI sp) (const_int -20))) (reg:SI r4))
           (set (mem:SI (plus:SI (reg:SI sp) (const_int -16))) (reg:SI fp))
           (set (mem:SI (plus:SI (reg:SI sp) (const_int -12))) (reg:SI ip))
           (set (mem:SI (plus:SI (reg:SI sp) (const_int -8))) (reg:SI lr))
           (set (mem:SI (plus:SI (reg:SI sp) (const_int -4))) (reg:SI pc))
           (set (reg:SI sp) (plus:SI (reg:SI sp) (const_int -20)))
        ])
be unique?  match_parallel would verify the form (that the first sp offset
matches the negative stack adjustment, that it is multiple of reg size, that
the
last adjustment is -word size, that the offsets are consecutive etc.
Alternatively surround the first set's RHS reg into UNSPEC. 


-- 


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

[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1

[ramana at gcc dot gnu dot org]

------- Comment #8 from ramana at gcc dot gnu dot org  2010-03-18 09:25 -------
(In reply to comment #7)
> BTW, if the PRE_MODIFY representation doesn't work well, I'd say just using a
> PARALLEL with what the insn really does and checking that in the match_parallel
> predicate probably wouldn't clash with anything else.  If it would, you'd need
> to insert one UNSPEC somewhere.


The PRE_MODIFY representation wouldn't work because you still have the assert
in var-tracking.c under the check for PRE_MODIFY that this is a BLKmode. The
problem is more the BLKmode on the address. 

> The comments say that currently the pattern looks like:
>        (parallel [
>            (set (mem:BLK (pre_dec:BLK (reg:SI sp)))
>                 (unspec:BLK [(reg:SI r4)] UNSPEC_PUSH_MULT))
>            (use (reg:SI 11 fp))
>            (use (reg:SI 12 ip))
>            (use (reg:SI 14 lr))
>            (use (reg:SI 15 pc))
>         ])
> with the REG_FRAME_RELATED_EXPR:
>       (sequence [
>            (set (reg:SI sp) (plus:SI (reg:SI sp) (const_int -20)))
>            (set (mem:SI (reg:SI sp)) (reg:SI r4))
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int 4))) (reg:SI fp))
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int 8))) (reg:SI ip))
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int 12))) (reg:SI lr))
>         ])
> So, would a parallel like:
>        (parallel [
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int -20))) (reg:SI r4))
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int -16))) (reg:SI fp))
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int -12))) (reg:SI ip))
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int -8))) (reg:SI lr))
>            (set (mem:SI (plus:SI (reg:SI sp) (const_int -4))) (reg:SI pc))
>            (set (reg:SI sp) (plus:SI (reg:SI sp) (const_int -20)))
>         ])
> be unique?  match_parallel would verify the form (that the first sp offset
> matches the negative stack adjustment, that it is multiple of reg size, that
> the
> last adjustment is -word size, that the offsets are consecutive etc.
> Alternatively surround the first set's RHS reg into UNSPEC. 

Actually the comment is out of date and needs to be corrected. It need not be
fp, sp, pc, and lr but any 4 integer registers that we choose to store using
the push_multi scheme in the prologue. Let me go stare at the backend.



-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |bootstrap
           Priority|P1                          |P3


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

[Bug bootstrap/43399] [4.5 Regression] bootstrap failure in stage1

[ramana at gcc dot gnu dot org]

------- Comment #9 from ramana at gcc dot gnu dot org  2010-03-18 10:21 -------
Created an attachment (id=20139)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20139&action=view)
patch

Patch that makes the ICE disappear by converting these into mem:BLKmode
(pre_modify (Pmode)). I will submit a variation of this in the ARM backend
finally on gcc-patches@


-- 


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

[Bug target/43399] [4.5 Regression] bootstrap failure in stage1

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |ramana at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
          Component|bootstrap                   |target
           Priority|P3                          |P1
   Last reconfirmed|2010-03-17 22:43:30         |2010-03-18 13:36:03
               date|                            |


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

[Bug target/43399] [4.5 Regression] bootstrap failure in stage1

[jakub at gcc dot gnu dot org]

------- Comment #10 from jakub at gcc dot gnu dot org  2010-03-18 20:19 -------
Subject: Bug 43399

Author: jakub
Date: Thu Mar 18 20:18:53 2010
New Revision: 157550

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157550
Log:
        PR bootstrap/43399
        * var-tracking.c (adjust_mems) <case POST_MODIFY>: Allow BLKmode
        mem_mode.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/var-tracking.c


-- 


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

[Bug target/43399] [4.5 Regression] bootstrap failure in stage1

[ramana at gcc dot gnu dot org]

------- Comment #11 from ramana at gcc dot gnu dot org  2010-03-18 21:40 -------
Patch submitted here. 

http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00840.html


-- 


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

[Bug target/43399] [4.5 Regression] bootstrap failure in stage1

[robertcnelson at gmail dot com]

------- Comment #12 from robertcnelson at gmail dot com  2010-03-18 22:53 -------
(In reply to comment #11)
> Patch submitted here. 
> 
> http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00840.html
> 

My beagle just finished testing your initial patch, it looks good:
http://rcn-ee.homeip.net:81/dl/gcc/SVN-157476-trunk-c-armv7l-256-bug43399-testing-GOOD/

I'm starting a new build with this patch, but your testsuite will probably
finish first...

I tested gcc-4.4 last night and so far it looks safe, will continue to monitor: 
http://rcn-ee.homeip.net:81/dl/gcc/SVN-157518-gcc-4.4-armv7l-256/


-- 


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

[Bug target/43399] [4.5 Regression] bootstrap failure in stage1

[ramana at gcc dot gnu dot org]

------- Comment #13 from ramana at gcc dot gnu dot org  2010-03-19 15:58 -------
Subject: Bug 43399

Author: ramana
Date: Fri Mar 19 15:58:37 2010
New Revision: 157574

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157574
Log:
Fix PR target/43399

2010-03-19  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

       PR target/43399
       * config/arm/arm.c (emit_multi_reg_push): Update comments.
       Use PRE_MODIFY instead of PRE_DEC.
       (emit_sfm): Use PRE_MODIFY instead of PRE_DEC.
       (vfp_emit_fstmd): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/arm/arm.c


-- 


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

[Bug target/43399] [4.5 Regression] bootstrap failure in stage1

[ramana at gcc dot gnu dot org]

------- Comment #14 from ramana at gcc dot gnu dot org  2010-03-19 17:04 -------
Fixed.


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug target/43399] [4.5 Regression] bootstrap failure in stage1

[pinskia at gcc dot gnu dot org]

------- Comment #15 from pinskia at gcc dot gnu dot org  2010-03-19 18:19 -------
*** Bug 43444 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mirq-gccboogs at rere dot
                   |                            |qmqm dot pl


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