Bug 41535 - [4.5 Regression] Broken var location info after scheduling
Summary: [4.5 Regression] Broken var location info after scheduling
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: debug (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: 4.5.0
Assignee: Alexandre Oliva
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-01 15:57 UTC by Andreas Krebbel
Modified: 2009-10-18 04:57 UTC (History)
2 users (show)

See Also:
Host: s390x-ibm-linux
Target: s390x-ibm-linux
Build: s390x-ibm-linux
Known to work:
Known to fail:
Last reconfirmed: 2009-10-07 07:23:25


Attachments
Testcase (501 bytes, patch)
2009-10-01 15:58 UTC, Andreas Krebbel
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Krebbel 2009-10-01 15:57:45 UTC
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_error@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.
Comment 1 Andreas Krebbel 2009-10-01 15:58:46 UTC
Created attachment 18687 [details]
Testcase

Compile with -O2 -fPIC -g
Comment 2 Alexandre Oliva 2009-10-07 07:23:05 UTC
Thanks for the bug report, confirmed, looking into it.
Comment 3 Alexandre Oliva 2009-10-17 06:29:29 UTC
Subject: Bug 41535

Author: aoliva
Date: Sat Oct 17 06:28:43 2009
New Revision: 152927

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152927
Log:
PR debug/41535
* sched-deps.c (depl_on_debug_p): New.
(attach_dep_link): Reject debug deps before nondebug deps.
(add_to_deps_list): Insert debug deps after nondebug deps.
(sd_lists_empty_p): Stop at first nonempty list.  Disregard debug
deps.
(sd_add_dep): Do not reject debug deps.
(add_insn_mem_dependence): Don't count debug deps.
(remove_from_deps): Likewise.
(sched_analyze_2): Set up mem deps on debug insns.
(sched_analyze_insn): Record reg uses for deps on debug insns.
* haifa-sched.c (schedule_insn): Reset deferred debug insn.  Don't
try_ready nondebug insn after debug insn.
* ddg.c (create_ddg_dep_from_intra_loop_link,
create_ddg_dep_no_link): Don't reject debug deps.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ddg.c
    trunk/gcc/haifa-sched.c
    trunk/gcc/sched-deps.c

Comment 4 Alexandre Oliva 2009-10-18 04:57:42 UTC
Fixed