[Bug target/42509] New: bootstrap failure in stage3 (integer overflow in preprocessor expression)

[Bug target/42509] New: bootstrap failure in stage3 (integer overflow in preprocessor expression)

[doko at ubuntu dot com]

current trunk (including all changes from 20091223), native build configured
with --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16
--with-mode=thumb, fails in stage3 (--with-mode=thumb the option to trigger
this):

if [ x"-fPIC" != x ]; then \
          /home/packages/gcc/4.5/gcc-4.5-4.5-20091223/build/./prev-gcc/xgcc
-B/home/packages/gcc/4.5/gcc-4.5-4.5-20091223/build/./prev-gcc/
-B/usr/arm-linux-gnueabi/bin/ -B/usr/arm-linux-gnueabi/bin/
-B/usr/arm-linux-gnueabi/lib/ -isystem /usr/arm-linux-gnueabi/include -isystem
/usr/arm-linux-gnueabi/sys-include    -c -DHAVE_CONFIG_H -g -O2
-fno-stack-protector  -I. -I../../src/libiberty/../include  -W -Wall
-Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fPIC
../../src/libiberty/sha1.c -o pic/sha1.o; \
        else true; fi
../../src/libiberty/sha1.c:46:3: error: #error "invalid BLOCKSIZE"
make[5]: *** [sha1.o] Error 1
make[5]: Leaving directory
`/home/packages/gcc/4.5/gcc-4.5-4.5-20091223/build/libiberty'
make[4]: *** [all-stage3-libiberty] Error 2

#define BLOCKSIZE 4096
#if BLOCKSIZE % 64 != 0
# error "invalid BLOCKSIZE"
#endif

building with -O0 doesn't show the error, just adding -save-temps as well :-/

going on with the build, more warnings:

../../src/gcc/hwint.h:59:5: warning: integer overflow in preprocessor
expression

#if HOST_BITS_PER_LONG >= 64 || !defined NEED_64BIT_HOST_WIDE_INT

../../src/gcc/../libcpp/include/cpplib.h:251:27: warning: integer overflow in
preprocessor expression

#if CHAR_BIT * SIZEOF_INT >= 32


-- 
           Summary: bootstrap failure in stage3 (integer overflow in
                    preprocessor expression)
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: doko at ubuntu dot com
GCC target triplet: arm-linux-gnueabi


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

[Bug target/42509] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[ramana at gcc dot gnu dot org]

-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-12-29 10:08:55
               date|                            |


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

[Bug target/42509] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[ramana at gcc dot gnu dot org]

------- Comment #1 from ramana at gcc dot gnu dot org  2009-12-30 23:54 -------
Mine.


-- 

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
   Last reconfirmed|2009-12-29 10:08:55         |2009-12-30 23:54:53
               date|                            |


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

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2009-12-31 15:21 -------
Primary target fails to bootstrap.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build
           Priority|P3                          |P1
            Summary|bootstrap failure in stage3 |[4.5 Regression] bootstrap
                   |(integer overflow in        |failure in stage3 (integer
                   |preprocessor expression)    |overflow in preprocessor
                   |                            |expression)
   Target Milestone|---                         |4.5.0


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

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[ramana at gcc dot gnu dot org]

------- Comment #3 from ramana at gcc dot gnu dot org  2010-01-06 12:26 -------
[I don't see the first build breakage with libiberty but the second problem
with "integer overflow in expressions"] . I am trying a full checking build on
a board but that's taking some time to complete !

With some more digging , the problem appears to be with miscompiling
_cpp_parse_expr in libcpp/expr.o in stage2. By recompiling expr.o with -O1 and
recreating the stage2 compiler the bootstrap proceeded further without the
error message. The other work around was to turn off inlining for the "reduce"
function in the libcpp/expr.c and then things seemed to work better.

Looks like a miscompiled stage2 compiler.


-- 


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

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[debian-gcc at lists dot debian dot org]

------- Comment #4 from debian-gcc at lists dot debian dot org  2010-01-07 13:53 -------
a build with BOOT_CFLAGS set to -g -O1 succeeds

  Matthias


-- 


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

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2010-03-15 13:23 -------
Ping.

Is native bootstrap not important for arm?  If so please downgrade to P2. 
Thanks.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nickc at redhat dot com,
                   |                            |richard dot earnshaw at arm
                   |                            |dot com


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

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[laurent at guerby dot net]

------- Comment #6 from laurent at guerby dot net  2010-03-15 17:36 -------
As Matthias said this is a --with-mode=thumb issue, people not using this
option have no issue bootstraping natively on arm:

http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01254.html
http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01186.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=42509

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[ramana at gcc dot gnu dot org]

------- Comment #7 from ramana at gcc dot gnu dot org  2010-03-16 08:57 -------
(In reply to comment #6)
> As Matthias said this is a --with-mode=thumb issue, people not using this
> option have no issue bootstraping natively on arm:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01254.html
> http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01186.html
> 




I spent some time last night playing with this and have a smaller testcase as
below where the stage2 pre-processor seems to generate a warning which is
wrong.


$>cat /tmp/test.c
#if 3 * -2 != 6
#error
#endif

/tmp/test.c:1:12: warning: integer overflow in preprocessor expression
/tmp/test.c:2:2: error: #error


-- 


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

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2010-03-16 13:55 -------
Downgrading to P2 based on Josephs comments.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2


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

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rearnsha at gcc dot gnu dot org]

------- Comment #9 from rearnsha at gcc dot gnu dot org  2010-04-01 15:02 -------
This is a miscompilation during stage2.  The file libcpp/expr.c is miscompiled.

The problem is occurring in num_positive, which ends up generating a shift of a
long long right by 63.  The code generated is creating spills that are of
SImode variables for the shift output, but then the result is being loaded back
as a DImode object.

Due to scheduling, one of the stores is being moved incorrectly after the load
and we get the following assembly fragment:

    342c:       fa2b fb02       lsr.w   fp, fp, r2
    3430:       fa0c f003       lsl.w   r0, ip, r3
    3434:       fa2c f301       lsr.w   r3, ip, r1
    3438:       fa2c f202       lsr.w   r2, ip, r2
    343c:       ea40 000b       orr.w   r0, r0, fp
    3440:       9245            str     r2, [sp, #276]  ; 0x114  <- first part
of store
    3442:       4686            mov     lr, r0
    3444:       2201            movs    r2, #1
    3446:       ea1e 0e21       ands.w  lr, lr, r1, asr #32
    344a:       bf38            it      cc
    344c:       469e            movcc   lr, r3
    344e:       a944            add     r1, sp, #272    ; 0x110
    3450:       e9d1 0100       ldrd    r0, r1, [r1]         <- Load back
    3454:       2300            movs    r3, #0
    3456:       f8cd e110       str.w   lr, [sp, #272]  ; 0x110 <- Second part
(oops, too late).


-- 


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

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rearnsha at gcc dot gnu dot org]

------- Comment #10 from rearnsha at gcc dot gnu dot org  2010-04-01 15:11 -------
Insn sequence from postreload dump (order is correct):

(insn 4979 1883 4589 173 /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c:1281
(set (mem/c:SI (plus:SI (reg/f:SI 13 sp)
                (const_int 276 [0x114])) [87 %sfp+-540 S4 A64])
        (reg:SI 2 r2)) 585 {*thumb2_movsi_vfp} (nil))

(insn 4589 4979 4980 173 /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c:1281
(set (reg:DI 2 r2 [1071])
        (const_int 1 [0x1])) 587 {*thumb2_movdi_vfp} (expr_list:REG_EQUIV
(const_int 1 [0x1])
        (nil)))

(insn 4980 4589 4981 173 /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c:1281
(set (reg:SI 1 r1)
        (plus:SI (reg/f:SI 13 sp)
            (const_int 272 [0x110]))) 4 {*arm_addsi3} (nil))

(insn 4981 4980 1885 173 /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c:1281
(set (reg:DI 0 r0)
        (mem/c:DI (reg:SI 1 r1) [87 %sfp+-544 S8 A64])) 587 {*thumb2_movdi_vfp}
(nil))

(insn 1885 4981 1887 173 /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c:1281
(set (reg:DI 2 r2 [1070])
        (and:DI (reg:DI 2 r2 [1071])
            (reg:DI 0 r0))) 64 {anddi3} (expr_list:REG_EQUAL (and:DI (mem/c:DI
(plus:SI (reg/f:SI 13 sp)
                    (const_int 272 [0x110])) [87 %sfp+-544 S8 A64])
            (const_int 1 [0x1]))
        (nil)))


-- 


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

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rearnsha at gcc dot gnu dot org]

------- Comment #11 from rearnsha at gcc dot gnu dot org  2010-04-01 15:32 -------
Created an attachment (id=20278)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20278&action=view)
compressed source for bug

Compiled with
/home/rearnsha/gnu/gcc/trunkd16/./stage1-gcc/xgcc
-B/home/rearnsha/gnu/gcc/trunkd16/./stage1-gcc/
-B/usr/local/armv7l-unknown-linux-gnueabi/bin/
-B/usr/local/armv7l-unknown-linux-gnueabi/bin/
-B/usr/local/armv7l-unknown-linux-gnueabi/lib/ -isystem
/usr/local/armv7l-unknown-linux-gnueabi/include -isystem
/usr/local/armv7l-unknown-linux-gnueabi/sys-include    
-I/home/rearnsha/gnusrc/gcc/trunk/libcpp -I.
-I/home/rearnsha/gnusrc/gcc/trunk/libcpp/../include
-I/home/rearnsha/gnusrc/gcc/trunk/libcpp/include  -g -O2 -W -Wall
-Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wc++-compat -pedantic
-Wno-long-long -Werror -I/home/rearnsha/gnusrc/gcc/trunk/libcpp -I.
-I/home/rearnsha/gnusrc/gcc/trunk/libcpp/../include
-I/home/rearnsha/gnusrc/gcc/trunk/libcpp/include  -c -o expr.o -MT expr.o -MMD
-MP -MF .deps/expr.Tpo /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c
-save-temps

Note, compiler was configured with:
'--with-cpu=cortex-a9' '--with-fpu=vfpv3-d16' '--with-float=softfp'
'--with-mode=thumb' 


-- 


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

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[ramana at gcc dot gnu dot org]

------- Comment #12 from ramana at gcc dot gnu dot org  2010-04-01 15:55 -------
I see this on arm-eabi cross with gcc version 4.5.0 20100401 (experimental)
[trunk revision 157899] (GCC) 

With the following command line options -

./xgcc -B`pwd` -S -O2 -mthumb -mcpu=cortex-a9 -mfpu=vfpv3-d16 ~/expr.i -da -g


In 203r.sched2 I see the following insn sequence which appears to be wrong to
my naked eye. 


(insn 5045 1929 5046 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (set (reg:SI 1
r1)
        (plus:SI (reg/f:SI 13 sp)
            (const_int 272 [0x110]))) 4 {*arm_addsi3} (nil))

(insn:TI 5046 5045 6004 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (set
(reg:DI 0 r0)
        (mem/c:DI (reg:SI 1 r1) [87 %sfp S8 A64])) 587 {*thumb2_movdi_vfp}
(nil))

(insn 6004 5046 5042 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (parallel [
            (set (reg:SI 3 r3 [+4 ])
                (const_int 0 [0x0]))
            (clobber (reg:CC 24 cc))
        ]) 704 {*thumb2_movsi_shortim} (expr_list:REG_UNUSED (reg:CC 24 cc)
        (nil)))

(insn:TI 5042 6004 6002 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (set
(mem/c:SI (plus:SI (reg/f:SI 13 sp)
                (const_int 272 [0x110])) [87 %sfp+-544 S4 A64])
        (reg:SI 14 lr)) 585 {*thumb2_movsi_vfp} (expr_list:REG_DEAD (reg:SI 14
lr)
        (nil)))

(insn:TI 6002 5042 6003 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (parallel [
            (set (reg:SI 3 r3 [+4 ])
                (and:SI (reg:SI 3 r3 [+4 ])
                    (reg:SI 1 r1 [+4 ])))
            (clobber (reg:CC 24 cc))
        ]) 700 {*thumb2_alusi3_short} (expr_list:REG_DEAD (reg:SI 1 r1 [+4 ])
        (expr_list:REG_UNUSED (reg:CC 24 cc)
            (nil))))


-- 


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

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[ramana at gcc dot gnu dot org]

------- Comment #13 from ramana at gcc dot gnu dot org  2010-04-01 17:11 -------
(In reply to comment #12)
> I see this on arm-eabi cross with gcc version 4.5.0 20100401 (experimental)
> [trunk revision 157899] (GCC) 
> 
> With the following command line options -
> 
> ./xgcc -B`pwd` -S -O2 -mthumb -mcpu=cortex-a9 -mfpu=vfpv3-d16 ~/expr.i -da -g

Correction - this should read 

./xgcc -B`pwd` -S -O2 -mthumb -mcpu=cortex-a9 -mfpu=vfpv3-d16 ~/expr.i -da -g
-mfloat-abi=softfp





> 
> In 203r.sched2 I see the following insn sequence which appears to be wrong to
> my naked eye. 
> 
> 
> (insn 5045 1929 5046 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (set (reg:SI 1
> r1)
>         (plus:SI (reg/f:SI 13 sp)
>             (const_int 272 [0x110]))) 4 {*arm_addsi3} (nil))
> 
> (insn:TI 5046 5045 6004 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (set
> (reg:DI 0 r0)
>         (mem/c:DI (reg:SI 1 r1) [87 %sfp S8 A64])) 587 {*thumb2_movdi_vfp}
> (nil))
> 
> (insn 6004 5046 5042 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (parallel [
>             (set (reg:SI 3 r3 [+4 ])
>                 (const_int 0 [0x0]))
>             (clobber (reg:CC 24 cc))
>         ]) 704 {*thumb2_movsi_shortim} (expr_list:REG_UNUSED (reg:CC 24 cc)
>         (nil)))
> 
> (insn:TI 5042 6004 6002 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (set
> (mem/c:SI (plus:SI (reg/f:SI 13 sp)
>                 (const_int 272 [0x110])) [87 %sfp+-544 S4 A64])
>         (reg:SI 14 lr)) 585 {*thumb2_movsi_vfp} (expr_list:REG_DEAD (reg:SI 14
> lr)
>         (nil)))
> 
> (insn:TI 6002 5042 6003 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (parallel [
>             (set (reg:SI 3 r3 [+4 ])
>                 (and:SI (reg:SI 3 r3 [+4 ])
>                     (reg:SI 1 r1 [+4 ])))
>             (clobber (reg:CC 24 cc))
>         ]) 700 {*thumb2_alusi3_short} (expr_list:REG_DEAD (reg:SI 1 r1 [+4 ])
>         (expr_list:REG_UNUSED (reg:CC 24 cc)
>             (nil))))
> 

(In reply to comment #12)
> I see this on arm-eabi cross with gcc version 4.5.0 20100401 (experimental)
> [trunk revision 157899] (GCC) 
> 
> With the following command line options -
> 
> ./xgcc -B`pwd` -S -O2 -mthumb -mcpu=cortex-a9 -mfpu=vfpv3-d16 ~/expr.i -da -g
> 
> 
> In 203r.sched2 I see the following insn sequence which appears to be wrong to
> my naked eye. 
> 
> 
> (insn 5045 1929 5046 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (set (reg:SI 1
> r1)
>         (plus:SI (reg/f:SI 13 sp)
>             (const_int 272 [0x110]))) 4 {*arm_addsi3} (nil))
> 
> (insn:TI 5046 5045 6004 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (set
> (reg:DI 0 r0)
>         (mem/c:DI (reg:SI 1 r1) [87 %sfp S8 A64])) 587 {*thumb2_movdi_vfp}
> (nil))
> 
> (insn 6004 5046 5042 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (parallel [
>             (set (reg:SI 3 r3 [+4 ])
>                 (const_int 0 [0x0]))
>             (clobber (reg:CC 24 cc))
>         ]) 704 {*thumb2_movsi_shortim} (expr_list:REG_UNUSED (reg:CC 24 cc)
>         (nil)))
> 
> (insn:TI 5042 6004 6002 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (set
> (mem/c:SI (plus:SI (reg/f:SI 13 sp)
>                 (const_int 272 [0x110])) [87 %sfp+-544 S4 A64])
>         (reg:SI 14 lr)) 585 {*thumb2_movsi_vfp} (expr_list:REG_DEAD (reg:SI 14
> lr)
>         (nil)))
> 
> (insn:TI 6002 5042 6003 167 /home/ramrad01/trunk/libcpp/expr.c:1281 (parallel [
>             (set (reg:SI 3 r3 [+4 ])
>                 (and:SI (reg:SI 3 r3 [+4 ])
>                     (reg:SI 1 r1 [+4 ])))
>             (clobber (reg:CC 24 cc))
>         ]) 700 {*thumb2_alusi3_short} (expr_list:REG_DEAD (reg:SI 1 r1 [+4 ])
>         (expr_list:REG_UNUSED (reg:CC 24 cc)
>             (nil))))
> 


-- 


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

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rearnsha at gcc dot gnu dot org]

------- Comment #14 from rearnsha at gcc dot gnu dot org  2010-04-01 19:30 -------
It appears that some of the annotations on the DImode reload are incorrect.

The store insn contains
(mem/c:SI (plus:SI (reg/f:SI 13 sp)
        (const_int 276 [0x114])) [87 %sfp+-540 S4 A64])

and the load contains

(mem/c:DI (reg:SI 1 r1) [87 %sfp S8 A64])

where r1 has the value SP+272
Note that despite this, the %sfp expressions differ by 540 bytes and as a
result nonoverlapping_memrefs_p declares the operations not to overlap.


-- 


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

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rearnsha at gcc dot gnu dot org]

------- Comment #15 from rearnsha at gcc dot gnu dot org  2010-04-01 22:04 -------
In expr.i.194r.dse2 the DImode load insn contains
(insn 4435 4434 5070 176 /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c:1281
(set (reg:DI 0 r0)
        (mem/c:DI (reg:SI 1 r1) [87 %sfp+-544 S8 A64])) 587 {*thumb2_movdi_vfp}
(nil))

However, in expr.i.195r.csa it has been converted to
(insn 4435 5240 5070 335 /home/rearnsha/gnusrc/gcc/trunk/libcpp/expr.c:1281
(set (reg:DI 0 r0)
        (mem/c:DI (reg:SI 1 r1) [87 %sfp S8 A64])) 587 {*thumb2_movdi_vfp}
(nil))

This seems to occur when it moves it to a new BB.

There doesn't seem to be an obvious option that disables the csa pass, short of
turning off all optimization.


-- 


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

[Bug target/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rearnsha at gcc dot gnu dot org]

------- Comment #16 from rearnsha at gcc dot gnu dot org  2010-04-01 22:43 -------
Hmm, actually the only bit of that pass that runs is a cleanup_cfg with
cross-jumping.


-- 


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

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rearnsha at gcc dot gnu dot org]

------- Comment #17 from rearnsha at gcc dot gnu dot org  2010-04-01 23:33 -------
So what is happening is that the cfg cleanup pass in the CSA pass is merging
the tails of two basic blocks.  These blocks both contain an insn that loads a
DI value into R0/R1 from the address in R1.  Because the 'base' values for the
two loads are different (and the calculation for that is not merged),
merge_memattrs squishes the MEM_OFFSET field, setting it to NULL_RTX.
The BBRO pass then splits this set of insns up again and puts them back in
their original BBs.
Finally the scheduling pass runs and calls nonoverlapping_memrefs_p on the load
instruction and a preceding store.  That then appears to assume that the two
memory accesses cannot overlap and thus cannot alias each other; and finally
the scheduler moves the store after the load.

This smells very generic to me so setting back to P3 for release maintainer
review.


-- 

rearnsha at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |middle-end
           Keywords|                            |wrong-code
           Priority|P2                          |P3
   Last reconfirmed|2009-12-30 23:54:53         |2010-04-01 23:33:57
               date|                            |


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

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[ramana at gcc dot gnu dot org]

------- Comment #18 from ramana at gcc dot gnu dot org  2010-04-02 00:01 -------

A work around I tried was to make cross-jumping run dependent on CSA which is
probably a heavy weight work around to what looks like a different problem. It
ended up retaining the correct ALIAS fields in this case but that's a heavy
weight solution and will in most likely hood make this bug go latent again. 

I'm travelling the next few days with minimal network access and given this
needs a MI expert to look at this - so can't actively work on this till I get
back next Tuesday . Hence un-assigning myself from it. 


Index: combine-stack-adj.c
===================================================================
--- combine-stack-adj.c (revision 157912)
+++ combine-stack-adj.c (working copy)
@@ -552,7 +552,6 @@ gate_handle_stack_adjustments (void)
 static unsigned int
 rest_of_handle_stack_adjustments (void)
 {
-  cleanup_cfg (flag_crossjumping ? CLEANUP_CROSSJUMP : 0);

   /* This is kind of a heuristic.  We need to run combine_stack_adjustments
      even for machines with possibly nonzero RETURN_POPS_ARGS
@@ -562,6 +561,7 @@ rest_of_handle_stack_adjustments (void)
   if (!ACCUMULATE_OUTGOING_ARGS)
 #endif
     {
+      cleanup_cfg (flag_crossjumping ? CLEANUP_CROSSJUMP : 0);
       df_note_add_problem ();
       df_analyze ();
       combine_stack_adjustments ();


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|ramana at gcc dot gnu dot   |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[ramana at gcc dot gnu dot org]

------- Comment #19 from ramana at gcc dot gnu dot org  2010-04-02 08:07 -------
A bootstrap on an A9 board last night with :

/home/ramrad01/trunk/configure --enable-languages=c --with-mode=thumb
--with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-float=softfp using 

gcc version 4.5.0 20100401 (experimental) [trunk revision 157933] (GCC)

succeeded. So that's a heavy weight work-around which might cause perf.
regressions for the ARM port because it effectively disables cross-jumping.

Anyway more later.  

cheers
Ramana 


-- 


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

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rguenth at gcc dot gnu dot org]

------- Comment #20 from rguenth at gcc dot gnu dot org  2010-04-02 12:09 -------
The obvious bug is that nonoverlapping_memrefs_p thinks that a NULL
MEM_OFFSET is equal to MEM_OFFSET == const0_rtx.  It is not, it's
"unknown offset".

The following should fix that.

Index: gcc/alias.c
===================================================================
--- gcc/alias.c (revision 157942)
+++ gcc/alias.c (working copy)
@@ -2268,6 +2268,10 @@ nonoverlapping_memrefs_p (const_rtx x, c
           : MEM_SIZE (rtly) ? INTVAL (MEM_SIZE (rtly)) :
           -1);

+  /* If the offset is unknown we cannot determine anything.  */
+  if (!moffsetx || !moffsety)
+    return 0;
+
   /* If we have an offset for either memref, it can update the values computed
      above.  */
   if (moffsetx)


-- 


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

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2010-04-02 12:15 -------
Or rather the code tries to account for that but fails to notice that
the spill-slot decl isn't really a decl.  Thus the following is better:

Index: gcc/alias.c
===================================================================
--- gcc/alias.c (revision 157942)
+++ gcc/alias.c (working copy)
@@ -2147,6 +2147,11 @@ nonoverlapping_memrefs_p (const_rtx x, c
   if (exprx == 0 || expry == 0)
     return 0;

+  /* We can only handle real decls, not the fake spill slot.  */
+  if (exprx == get_spill_slot_decl (false)
+      || expry == get_spill_slot_decl (false))
+    return 0;
+
   /* If both are field references, we may be able to determine something.  */
   if (TREE_CODE (exprx) == COMPONENT_REF
       && TREE_CODE (expry) == COMPONENT_REF


-- 


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

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rguenth at gcc dot gnu dot org]

------- Comment #22 from rguenth at gcc dot gnu dot org  2010-04-02 12:33 -------
Or a combination of both.  In particular the code doesn't account for
the negative offsets we offset the spill-slot decl with when trying to
handle a NULL MEM_OFFSET conservatively.

I wonder what sizex / sizey is for the spill-slot-decl, or rather what
mode or size it has ...

Least pessimizing patch follows, it looks like nobody else would
disambiguate spill slots otherwise (apart from the tree oracle calls).

Index: gcc/alias.c
===================================================================
--- gcc/alias.c (revision 157942)
+++ gcc/alias.c (working copy)
@@ -2147,6 +2147,13 @@ nonoverlapping_memrefs_p (const_rtx x, c
   if (exprx == 0 || expry == 0)
     return 0;

+  /* For spill-slot accesses make sure we have valid offsets.  */
+  if ((exprx == get_spill_slot_decl (false)
+       && ! MEM_OFFSET (x))
+      || (expry == get_spill_slot_decl (false)
+         && ! MEM_OFFSET (y)))
+    return 0;
+
   /* If both are field references, we may be able to determine something.  */
   if (TREE_CODE (exprx) == COMPONENT_REF
       && TREE_CODE (expry) == COMPONENT_REF


-- 


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

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rguenth at gcc dot gnu dot org]

------- Comment #23 from rguenth at gcc dot gnu dot org  2010-04-02 13:54 -------
(In reply to comment #17)
> So what is happening is that the cfg cleanup pass in the CSA pass is merging
> the tails of two basic blocks.  These blocks both contain an insn that loads a
> DI value into R0/R1 from the address in R1.  Because the 'base' values for the
> two loads are different (and the calculation for that is not merged),
> merge_memattrs squishes the MEM_OFFSET field, setting it to NULL_RTX.
> The BBRO pass then splits this set of insns up again and puts them back in
> their original BBs.
> Finally the scheduling pass runs and calls nonoverlapping_memrefs_p on the load
> instruction and a preceding store.  That then appears to assume that the two
> memory accesses cannot overlap and thus cannot alias each other; and finally
> the scheduler moves the store after the load.
> 
> This smells very generic to me so setting back to P3 for release maintainer
> review.

In addition to making nonoverlapping_memrefs_p more robust here I wonder
how we ended up with mismatching MEM_OFFSETs in the first place.

Anyway, it would be nice if somebody could verify if the patch in
comment #22 fixes the issue on the arm.  I will bootstrap & test it
on x86_64 today.


-- 


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

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rguenth at gcc dot gnu dot org]

------- Comment #24 from rguenth at gcc dot gnu dot org  2010-04-02 15:20 -------
Alternative patch as suggested by Richard on IRC - it doesn't make sense to
retain MEM_EXPR w/o MEM_OFFSET.

Index: gcc/cfgcleanup.c
===================================================================
--- gcc/cfgcleanup.c    (revision 157942)
+++ gcc/cfgcleanup.c    (working copy)
@@ -891,18 +891,14 @@ merge_memattrs (rtx x, rtx y)
              set_mem_alias_set (y, 0);
            }

-         if (! mem_expr_equal_p (MEM_EXPR (x), MEM_EXPR (y)))
+         if (! mem_expr_equal_p (MEM_EXPR (x), MEM_EXPR (y))
+             || MEM_OFFSET (x) != MEM_OFFSET (y))
            {
              set_mem_expr (x, 0);
              set_mem_expr (y, 0);
              set_mem_offset (x, 0);
              set_mem_offset (y, 0);
            }
-         else if (MEM_OFFSET (x) != MEM_OFFSET (y))
-           {
-             set_mem_offset (x, 0);
-             set_mem_offset (y, 0);
-           }

          if (!MEM_SIZE (x))
            mem_size = NULL_RTX;


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|rguenther at suse dot de    |jakub at gcc dot gnu dot
                   |                            |org, rguenth at gcc dot gnu
                   |                            |dot org


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

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rguenth at gcc dot gnu dot org]

------- Comment #25 from rguenth at gcc dot gnu dot org  2010-04-02 16:14 -------
Ok, I reproduced the issue and comment #22 looks like the correct fix.
merge_memattrs is doing the right thing, just nonoverlapping_memrefs_p
conservative fallback for NULL MEM_OFFSET assumes DECLs are not offsetted
with negative offsets - which is not true for the spill slot decl.


-- 


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

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rguenth at gcc dot gnu dot org]

------- Comment #26 from rguenth at gcc dot gnu dot org  2010-04-03 17:14 -------
The bootstrap issue is fixed.


-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug middle-end/42509] [4.5 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[rguenth at gcc dot gnu dot org]

------- Comment #27 from rguenth at gcc dot gnu dot org  2010-04-03 17:15 -------
Subject: Bug 42509

Author: rguenth
Date: Sat Apr  3 17:14:44 2010
New Revision: 157954

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157954
Log:
2010-04-03  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42509
        * alias.c (nonoverlapping_memrefs_p): For spill-slot accesses
        require a non-NULL MEM_OFFSET.

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


-- 


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

[Bug middle-end/42509] [4.4 Regression] bootstrap failure in stage3 (integer overflow in preprocessor expression)

[steven at gcc dot gnu dot org]

------- Comment #28 from steven at gcc dot gnu dot org  2010-04-12 19:56 -------
Triggers in 4.4 with an out-of-tree port.
See http://gcc.gnu.org/ml/gcc/2010-04/msg00243.html


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
      Known to fail|                            |4.4.3
      Known to work|                            |4.5.0
         Resolution|FIXED                       |
            Summary|[4.5 Regression] bootstrap  |[4.4 Regression] bootstrap
                   |failure in stage3 (integer  |failure in stage3 (integer
                   |overflow in preprocessor    |overflow in preprocessor
                   |expression)                 |expression)


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

[Bug middle-end/42509] [4.4 Regression] nonoverlapping_memrefs_p misinterprets NULL MEM_OFFSET as const0_rtx

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|build                       |patch
            Summary|[4.4 Regression] bootstrap  |[4.4 Regression]
                   |failure in stage3 (integer  |nonoverlapping_memrefs_p
                   |overflow in preprocessor    |misinterprets NULL
                   |expression)                 |MEM_OFFSET as const0_rtx
   Target Milestone|4.5.0                       |4.4.4


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

[Bug middle-end/42509] [4.4 Regression] nonoverlapping_memrefs_p misinterprets NULL MEM_OFFSET as const0_rtx

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.4                       |4.4.5


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

[Bug middle-end/42509] [4.4 Regression] nonoverlapping_memrefs_p misinterprets NULL MEM_OFFSET as const0_rtx

[uweigand at gcc dot gnu dot org]

------- Comment #29 from uweigand at gcc dot gnu dot org  2010-07-28 18:00 -------
Subject: Bug 42509

Author: uweigand
Date: Wed Jul 28 18:00:08 2010
New Revision: 162650

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162650
Log:
        Backport from mainline:
        2010-04-03  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42509
        * alias.c (nonoverlapping_memrefs_p): For spill-slot accesses
        require a non-NULL MEM_OFFSET.

Modified:
    branches/gcc-4_4-branch/gcc/ChangeLog
    branches/gcc-4_4-branch/gcc/alias.c


-- 


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

[Bug middle-end/42509] [4.4 Regression] nonoverlapping_memrefs_p misinterprets NULL MEM_OFFSET as const0_rtx

[uweigand at gcc dot gnu dot org]

------- Comment #30 from uweigand at gcc dot gnu dot org  2010-07-28 18:01 -------
Backported fix to 4.4 branch as well.  The bug should now be fixed everywhere.


-- 

uweigand at gcc dot gnu dot org changed:

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


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