[Bug 836588]

[Jakub-gcc]

Note, can't be reproduced on the trunk, the strcmp isn't DCEd there, but
guess the problem is just latent there.

It looks like a target bug to me.  Before RTL loop opts we have:
(insn 91 90 92 13 (set (reg:SI 167)
        (unspec:SI [
                (const:SI (unspec:SI [
                            (symbol_ref/v/f:SI ("*.LC4") [flags 0x82]  <var_decl 0x7f5ebb0a5500 *.LC4>)
                            (const:SI (plus:SI (unspec:SI [
                                            (const_int 4 [0x4])
                                        ] 21)
                                    (const_int 8 [0x8])))
                        ] 27))
            ] 3)) pr48308.i:228 170 {pic_load_addr_32bit}
     (nil))

(insn 92 91 94 13 (set (reg:SI 167)
        (unspec:SI [
                (reg:SI 167)
                (const_int 8 [0x8])
                (const_int 4 [0x4])
            ] 4)) pr48308.i:228 173 {pic_add_dot_plus_eight}
     (expr_list:REG_EQUAL (symbol_ref/v/f:SI ("*.LC4") [flags 0x82]  <var_decl 0x7f5ebb0a5500 *.LC4>)
        (nil)))

and the pseudo 167 is then used to load one of the strcmp parameters.
Then (probably loop invariant motion) moves insn 91 before the loop, as it looks to be loop invariant, but insn 92 is kept in the loop.
Next during RA, the register pressure is high and thus pseudo 167 is spilled, so
before the loop there is a store.  Then during the *.csa pass DCE is performed and the strcmp is removed, which means insn 92 is removed as well, but the store before the loop of course is kept.  And there is no further DSE pass that would optimize that (now dead) store away.
So, IMHO arm_reorg needs to handle this case, find out what minipool entries don't have the corresponding UNSPEC_PIC_BASE insn and handle them somehow (either by emitting there a dummy 0 or similar, or trying to replace the insn with UNSPEC_PIC_SYM with something else, ...).
That said, perhaps it would be nice to help the loop optimizers somehow figure out that even the UNSPEC_PIC_BASE is loop invariant (wrap it into CONST?).

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gcc-4.5 in Ubuntu.
https://bugs.launchpad.net/bugs/836588

Title:
  armel FTBFS with gcc 4.5 org 4.6 O2 and fPIC

Status in The GNU Compiler Collection:
  In Progress
Status in Linaro GCC:
  Triaged
Status in “gcc-4.5” package in Ubuntu:
  Confirmed
Status in “gcc-4.6” package in Ubuntu:
  Confirmed
Status in “gmime2.4” package in Ubuntu:
  Fix Released

Bug description:
  A reference to an inexistent label in the asm file causes FTBFS.
  Using -O1 or dropping -fPIC works fine, so does gcc-4.4 with O2 and fPIC on.

  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../util -DGMIME_VERSION=\"2.4.26\" -DGMIME_MAJOR_VERSION=2 -DGMIME_MINOR_VERSION=4 -DGMIME_MICRO_VERSION=26 -DG_LOG_DOMAIN=\"gmime\" -DG_DISABLE_DEPRECATED -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pthread -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabi/glib-2.0/include  -O2  -c gmime-param.c  -fPIC  -o .libs/gmime-param.o
  /tmp/ccDqUYcb.s: Assembler messages:
  /tmp/ccDqUYcb.s:1153: Error: can't resolve `.rodata' {.rodata section} - `.LPIC20' {*UND* section}

To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc/+bug/836588/+subscriptions