[Bug target/48308] [4.6/4.7 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}

["ramana at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #19 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> 2012-01-13 09:07:48 UTC ---
(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