[Bug 836588]

[Ramana-gcc]

(In reply to comment #14)
> Note, can't be reproduced on the trunk, the strcmp isn't DCEd there, but guess
> the problem is just latent there.

Latent still in trunk with the testcase - you can try it with -fdbg-
cnt=cprop:0 with the first reduced testcase and you should be able to
see the same behaviour with trunk. The other testcase which is in
PR50313 also fails with the same error on trunk (with -Os -fPIC
-mcpu=arm9tdmi -marm )

The problem with reduced^2 testcase or reduced testcase appears to get
fixed if we add LOG_LINKS to keep track of the dummy i1 in the form of a
patch of the following nature.

combine.c: try_combine attempts to create a dummy i1 instruction in case
i1 is NULL and i2 looks like

	(parallel [(set (reg:CC X) (compare:CC OP (const_int 0)))
		   (set Y OP)])

which is exactly how the intermediate instruction looks

(parallel [
        (set (reg:CC 24 cc)
            (compare:CC (reg:SI 0 r0)
                (const_int 0 [0])))
        (set (reg:SI 168)
            (reg:SI 0 r0))
    ])

i1 now becomes

  (set (reg:SI 168)
            (reg:SI 0 r0))

and i2 becomes

    (set (reg:CC 24 cc)
            (compare:CC (reg:SI 0 r168)
                (const_int 0 [0])))

but there are no LOG_LINKS to indicate that even when we've created the
dummy i1 - i2 actually feeds into i1. After changing try_combine[1] to
create a LOG_LINKS to indicate this relationship between i1 and i2 we no
longer eliminate the wrong strcmp call and therefore this should IMHO be
the handled in combine rather than faffing around in the backend.

However this doesn't fix the testcase from PR50313 (gmime.i) which
prima-facie appeared to exhibit the same behaviour as this particular
testcase and that needs reopening and further investigation to be sure
that the IR is valid when cfgcleanup decides to eliminate the PIC insn
in.


cheers
Ramana


diff --git a/gcc/combine.c b/gcc/combine.c
index 4178870..f6b8769 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -2865,6 +2865,8 @@ try_combine (rtx i3, rtx i2, rtx i1, rtx i0, int *new_direct_jump_p,
          SUBST (PATTERN (i2), XVECEXP (PATTERN (i2), 0, 0));
          SUBST (XEXP (SET_SRC (PATTERN (i2)), 0),
                 SET_DEST (PATTERN (i1)));
+         LOG_LINKS (i2) = alloc_insn_link (i1, LOG_LINKS (i2));
+
        }
     }
 #endif

-- 
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