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