On s390x I see broken debug info generated for the attached C++
testcase (compile with -O2 -g -fPIC).
The debug info contains a symbol reference with a @GOTENT modifier
what should not happen (and is not accepted by gas):
.LLST3:
.8byte .LVL3-.Ltext0
.8byte .LVL4-.Ltext0
.2byte 0xa
.byte 0x9e
.uleb128 0x8
.8byte _ztist12future_er...@gotent
.8byte 0x0
.8byte 0x0
The problem is that the sched2 pass breaks the variable location
information by moving an insn setting r1 over a var_location debug
insn describing a variable location as being r1.
in 202.split4:
29: var_location r10
33: var_location r13 + 8
34: var_location r10
30: r1 = &(A got entry)
31: r1 = [r1]
83: [r13] = r2
32: r1 = [r1]
35: var_location A => r1 <-- problematic location information
36: [r13 + 8] = r10
37: [r13 + 16] = r1
79: r1 = &(B got entry)
41: r3 = [r1]
in 203.sched2:
...
32: r1 = [r1]
37: [r13 + 16] = r1
79: r1 = &(B got entry) <-- insn moved over 35
83: [r13] = r2
29: var_location r10
33: var_location r13 + 8
34: var_location r10
35: var_location r1 !!! the variable location gets corrupted
since insn 79 has been moved over it
36: [r13 + 8] = r10
41: r3 = [r1]
The variable locations are intended to stay right after the insn which
does the relevant assignment by generating an ANTI dep between them
but we also create deps between unrelated insns:
sched-deps.c:2790
if (prev && NONDEBUG_INSN_P (prev))
add_dependence (insn, prev, REG_DEP_ANTI);
This code creates a dependency between 83 and 29 (although the
assignment is unrelated). This together with the fact that all debug
insns are always been kept from being moved over each other makes all
the debug insns to get stuck after insn 83. Although in order to keep
the information correct insn 35 has to stay after 32.
--
Summary: Broken var location info after scheduling
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: krebbel at gcc dot gnu dot org
GCC build triplet: s390x-ibm-linux
GCC host triplet: s390x-ibm-linux
GCC target triplet: s390x-ibm-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41535