[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}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.3 |4.6.4 --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-01 14:39:21 UTC --- GCC 4.6.3 is being released.
[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}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #20 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-01-25 08:52:43 UTC --- Author: ramana Date: Wed Jan 25 08:52:39 2012 New Revision: 183512 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183512 Log: 2012-01-25 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR rtl-optimization/48308 * combine.c (enum undo_kind): Add UNDO_LINKS. (struct undo): Add member l to other_contents and where. (do_SUBST_LINK): New. (SUBST_LINK): New. (try_combine): Handle LOG_LINKS for the dummy i1 case. (undo_all): Handle UNDO_LINKS. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c
[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}
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
[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}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308
--- Comment #18 from Ramana Radhakrishnan ramana at gcc dot gnu.org
2012-01-11 18:15:05 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.
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?).
Found it I think- the problem is way before any of this . A transformation
in combine looks suspicious.
The first clue to all this was that the compiler was removing a call of strcmp
with .LC4 which is the constant string -noout . If you look at the testcase,
there is a use of noout afterwards which is to call :
if (!noout)
PEM_write_bio_Parameters(out,pkey);
However the condition
else if (strcmp(*args,-text) == 0)
text=1;
has a value of text set to 1.
However given text is not used later that is the only call
to strcmp that can be removed safely. However the strcmp of -text is retained
in the final code generated but the call to strcmp of -noout is the one
that's getting eliminated.
Here's the suspicious transformation after combine:
(insn 97 96 188 13 (set (reg:SI 168)
(reg:SI 0 r0)) ./t.i:41 624 {*arm_movsi_vfp}
(expr_list:REG_DEAD (reg:SI 0 r0)
(nil)))
(insn 188 97 189 13 (set (reg:CC 24 cc)
(compare:CC (reg:SI 168)
(const_int 0 [0]))) ./t.i:41 198 {*arm_cmpsi_insn}
(nil))
(insn 189 188 191 13 (set (reg/v:SI 136 [ badarg ])
(if_then_else:SI (eq (reg:CC 24 cc)
(const_int 0 [0]))
(reg:SI 168)
(const_int 0 [0]))) ./t.i:41 220 {*movsicc_insn}
(expr_list:REG_DEAD (reg:SI 168)
(nil)))
(insn 191 189 153 13 (set (reg/v:SI 135 [ noout ])
(if_then_else:SI (ne (reg:CC 24 cc)
(const_int 0 [0]))
(reg/v:SI 135 [ noout ])
(const_int 1 [0x1]))) ./t.i:41 220 {*movsicc_insn}
(expr_list:REG_DEAD (reg:CC 24 cc)
(nil)))
is transformed to :
(note 97 96 188 13 NOTE_INSN_DELETED)
(note 188 97 189 13 NOTE_INSN_DELETED)
(insn 189 188 191 13 (set (reg/v:SI 136 [ badarg ])
(const_int 0 [0])) ./t.i:41 624 {*arm_movsi_vfp}
(nil))
(insn 191 189 153 13 (parallel [
(set (reg/v:SI 135 [ noout ])
(if_then_else:SI (ne (reg:SI 168)
(const_int 0 [0]))
(reg/v:SI 135 [ noout ])
(const_int 1 [0x1])))
(clobber (reg:CC 24 cc))
]) ./t.i:41 273 {movcond}
(expr_list:REG_UNUSED (reg:CC 24 cc)
(expr_list:REG_DEAD (reg:SI 168)
(nil
Look at the use of reg:SI 168 in insn 191 rather than reg:SI r0 . That's where
it all goes pear shaped as we've now used reg:SI 168 which we've not defined
before. The other bits of info from .combine is as below.
Trying 97 - 188:
Successfully matched this instruction:
(parallel [
(set (reg:CC 24 cc)
(compare:CC (reg:SI 0 r0)
(const_int 0 [0])))
(set (reg:SI 168)
(reg:SI 0 r0))
])
and
[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}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #17 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-01-06 16:02:49 UTC --- I think it would be better to just generate a single insn early on and then to split it once the loop optimizers have had a chance to run. Then the optimizers should be able to throw the whole expression away if it's not needed and hoist it as a whole if it's inside a loop. Splitting it before sched1 would be ideal, but the split could be delayed until after reload if necessary.
[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}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-05 17:48:11 UTC --- Ramana (or some other ARM maintainer), could you please try to implement this? Thanks.
[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}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-22
16:05:52 UTC ---
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?).
[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}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #15 from Michael Hope michael.hope at linaro dot org 2011-12-22 16:07:46 UTC --- I'm away of holiday until the 4th of January. For anything urgent, please contact k...@linaro.org. -- Michael
[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}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 Madhu madhu_k515 at yahoo dot co.in changed: What|Removed |Added CC||madhu_k515 at yahoo dot ||co.in --- Comment #12 from Madhu madhu_k515 at yahoo dot co.in 2011-11-02 11:37:07 UTC --- Please tell me this bug is fixed in gcc 4.6.2 release? If this is fixed in gcc4.6.2 release can I use the fix patch into gcc 4.6-linaro? Thanks Regards, Madhu
[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}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #13 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-11-02 11:40:44 UTC --- (In reply to comment #12) Please tell me this bug is fixed in gcc 4.6.2 release? If this is fixed in gcc4.6.2 release can I use the fix patch into gcc 4.6-linaro? Thanks Regards, Madhu This has not been fixed yet. That's evident from the status of the bug. Ramana
[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}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.2 |4.6.3 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-26 17:14:01 UTC --- GCC 4.6.2 is being released.
[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}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #10 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-09-13 06:31:39 UTC --- *** Bug 50313 has been marked as a duplicate of this bug. ***
[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}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org 2011-09-07 07:53:23 UTC --- (In reply to comment #8) Not sure if this is a target or tree-optimization issue yet. The tree level change just exposed the issue really. I think you need to look at the RTL level to see where the label disappears.
[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}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ramana at gcc dot gnu.org |gnu.org |
[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}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
