From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24578 invoked by alias); 14 Dec 2011 14:34:28 -0000 Received: (qmail 24346 invoked by uid 22791); 14 Dec 2011 14:34:26 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Dec 2011 14:34:12 +0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/51517] [4.5/4.6/4.7 Regression] Wrong debug information for pointers with negative strides. Date: Wed, 14 Dec 2011 14:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.5.4 X-Bugzilla-Changed-Fields: Status Last reconfirmed CC Ever Confirmed Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-12/txt/msg01503.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51517 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2011-12-14 CC| |burnus at gcc dot gnu.org, | |jakub at gcc dot gnu.org, | |matz at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2011-12-14 14:33:50 UTC --- There are multiple issues here: 1) the fortran FE adds DECL_INITIAL to the span variable, which doesn't make any sense for an automatic variable (and isn't needed for TREE_STATIC either, because those are initialized to 0 by default). --- gcc/fortran/trans-decl.c.jj 2011-12-11 22:02:37.000000000 +0100 +++ gcc/fortran/trans-decl.c 2011-12-14 15:20:03.656835603 +0100 @@ -1434,7 +1434,6 @@ gfc_get_symbol_decl (gfc_symbol * sym) gfc_finish_var_decl (span, sym); TREE_STATIC (span) = TREE_STATIC (decl); DECL_ARTIFICIAL (span) = 1; - DECL_INITIAL (span) = build_int_cst (gfc_array_index_type, 0); GFC_DECL_SPAN (decl) = span; GFC_TYPE_ARRAY_SPAN (TREE_TYPE (decl)) = span; If the FE wants to initialize the span.N variable to zero when it is not TREE_STATIC, it really should add a statement to a right spot that initializes it to 0, having DECL_INITIAL does nothing and just confuses dwarf2out. 2) for some reason the span.0 variable doesn't get DECL_RTL during expansion, actually it gets it to one MEM location for the span.0_?? = 4; store and a different location for the span.0_?? = 44; store: /* For the benefit of debug information at -O0 (where vartracking doesn't run) record the place also in the base DECL if it's a normal variable (not a parameter). */ if (x && x != pc_rtx && TREE_CODE (SSA_NAME_VAR (t)) == VAR_DECL) { tree var = SSA_NAME_VAR (t); /* If we don't yet have something recorded, just record it now. */ if (!DECL_RTL_SET_P (var)) SET_DECL_RTL (var, x); /* If we have it set already to "multiple places" don't change this. */ else if (DECL_RTL (var) == pc_rtx) ; /* If we have something recorded and it's not the same place as we want to record now, we have multiple partitions for the same base variable, with different places. We can't just randomly chose one, hence we have to say that we don't know. This only happens with optimization, and there var-tracking will figure out the right thing. */ else if (DECL_RTL (var) != x) SET_DECL_RTL (var, pc_rtx); } Apparently we have multiple partitions for the same base variable at -O0 :(. The variable is !DECL_IGNORED_P, although it is DECL_ARTIFICIAL. Micha, any ideas why it got two partitions instead of just one as expected? The 1) patch would turn this from invalid debug info into valid, but incomplete, debug info. Figuring out 2) would supposedly turn it into valid complete debug info. And, one would hope that if/when the array descriptor format finally changes (is it now scheduled for 4.8, or later?) and stride will be in bytes rather than whatever units it currently is, this span.N stuff will be no longer needed.