Launchpad has imported 31 comments from the remote bug at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://documentation.ubuntu.com/launchpad/user/reference/bugs/multi-project-bugs/about-multi-project-bugs/#bugs-in-external-trackers. ------------------------------------------------------------------------ On 2009-12-26T12:03:24+00:00 Matthias Klose wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/0 ------------------------------------------------------------------------ On 2009-12-30T23:54:53+00:00 Ramana-gcc wrote: Mine. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/2 ------------------------------------------------------------------------ On 2009-12-31T15:21:44+00:00 Rguenth wrote: Primary target fails to bootstrap. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/3 ------------------------------------------------------------------------ On 2010-01-06T12:26:44+00:00 Ramana-gcc wrote: [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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/4 ------------------------------------------------------------------------ On 2010-01-07T13:53:24+00:00 Debian GCC maintainers wrote: a build with BOOT_CFLAGS set to -g -O1 succeeds Matthias Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/5 ------------------------------------------------------------------------ On 2010-03-15T13:23:27+00:00 Rguenth wrote: Ping. Is native bootstrap not important for arm? If so please downgrade to P2. Thanks. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/6 ------------------------------------------------------------------------ On 2010-03-15T17:36:02+00:00 Laurent GUERBY wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-snapshot/+bug/500524/comments/7 ------------------------------------------------------------------------ On 2010-03-16T08:57:33+00:00 Ramana-gcc wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-snapshot/+bug/500524/comments/8 ------------------------------------------------------------------------ On 2010-03-16T13:55:41+00:00 Rguenth wrote: Downgrading to P2 based on Josephs comments. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/9 ------------------------------------------------------------------------ On 2010-04-01T15:02:36+00:00 Rearnsha wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/10 ------------------------------------------------------------------------ On 2010-04-01T15:11:12+00:00 Rearnsha wrote: 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))) Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/11 ------------------------------------------------------------------------ On 2010-04-01T15:32:26+00:00 Rearnsha wrote: Created attachment 20278 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' Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/12 ------------------------------------------------------------------------ On 2010-04-01T15:55:39+00:00 Ramana-gcc wrote: 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)))) Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/13 ------------------------------------------------------------------------ On 2010-04-01T17:11:19+00:00 Ramana-gcc wrote: (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)))) > Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/14 ------------------------------------------------------------------------ On 2010-04-01T19:30:49+00:00 Rearnsha wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/15 ------------------------------------------------------------------------ On 2010-04-01T22:04:06+00:00 Rearnsha wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/16 ------------------------------------------------------------------------ On 2010-04-01T22:43:48+00:00 Rearnsha wrote: Hmm, actually the only bit of that pass that runs is a cleanup_cfg with cross-jumping. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/17 ------------------------------------------------------------------------ On 2010-04-01T23:33:57+00:00 Rearnsha wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-snapshot/+bug/500524/comments/18 ------------------------------------------------------------------------ On 2010-04-02T00:01:34+00:00 Ramana-gcc wrote: 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 (); Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/19 ------------------------------------------------------------------------ On 2010-04-02T08:07:57+00:00 Ramana-gcc wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/20 ------------------------------------------------------------------------ On 2010-04-02T12:09:06+00:00 Rguenth wrote: 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) Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-snapshot/+bug/500524/comments/21 ------------------------------------------------------------------------ On 2010-04-02T12:15:08+00:00 Rguenth wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-snapshot/+bug/500524/comments/22 ------------------------------------------------------------------------ On 2010-04-02T12:33:33+00:00 Rguenth wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-snapshot/+bug/500524/comments/23 ------------------------------------------------------------------------ On 2010-04-02T13:54:09+00:00 Rguenth wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/24 ------------------------------------------------------------------------ On 2010-04-02T15:20:20+00:00 Rguenth wrote: 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; Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-snapshot/+bug/500524/comments/25 ------------------------------------------------------------------------ On 2010-04-02T16:14:40+00:00 Rguenth wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/26 ------------------------------------------------------------------------ On 2010-04-03T17:14:58+00:00 Rguenth wrote: The bootstrap issue is fixed. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/27 ------------------------------------------------------------------------ On 2010-04-03T17:15:07+00:00 Rguenth wrote: 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 <[email protected]> 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/28 ------------------------------------------------------------------------ On 2010-04-12T19:56:23+00:00 stevenb wrote: Triggers in 4.4 with an out-of-tree port. See http://gcc.gnu.org/ml/gcc/2010-04/msg00243.html Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc-snapshot/+bug/500524/comments/29 ------------------------------------------------------------------------ On 2010-07-28T18:00:30+00:00 Uweigand-gcc wrote: 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 <[email protected]> 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/33 ------------------------------------------------------------------------ On 2010-07-28T18:01:30+00:00 Uweigand-gcc wrote: Backported fix to 4.4 branch as well. The bug should now be fixed everywhere. Reply at: https://bugs.launchpad.net/ubuntu/+source/gcc- snapshot/+bug/500524/comments/34 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/500524 Title: bootstrap failure in stage3 (integer overflow in preprocessor expression) To manage notifications about this bug go to: https://bugs.launchpad.net/gcc/+bug/500524/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
