https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-04-16
CC| |aoliva at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
There seems to be multiple issues here.
One is a bug in the TARGET_RELOCATABLE handling in the powerpc backend, it
emits the LCL and LCF symbols in the IL, but then emits them into the actual
assembly only if some conditions are satisfied. If they make it through into
debug insns for some reason, that obviously results in the undefined
references.
Perhaps the target address legitimization should handle those, or if the
backend determines that it won't emit the symbols it should scan the IL for any
possible debug uses and reset them. I'm afraid there is nothing dwarf2out can
do for this.
And another thing is why valtrack during DSE2 emits a debug instruction
containing this.
At *.split2 we have:
(insn 36 35 37 2 (set (reg/v:SI 0 0 [orig:239 s2 ] [239])
(lshiftrt:SI (reg/v:SI 3 3 [orig:265 adler ] [265])
(const_int 16 [0x10])))
../../../../../../../../../rtems/c/src/lib/libbsp/powerpc/motorola_powerpc/bootloader/../../../powerpc/shared/b
(nil))
(debug_insn 37 36 39 2 (var_location:SI s2 (reg/v:SI 0 0 [orig:239 s2 ] [239]))
../../../../../../../../../rtems/c/src/lib/libbsp/powerpc/motorola_
(nil))
which LGTM.
But then during pro_and_epilogue pass, the insn 36 is removed (perhaps some
kind of fast DCE?), and instead a code in the prologue that uses register 0 for
something completely different is added, which results in the wrong-debug
because the debug insns weren't reset.
As a workaround, -fno-var-tracking-assignments should cure this.
