From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21561 invoked by alias); 7 Oct 2011 18:54:45 -0000 Received: (qmail 21550 invoked by uid 22791); 7 Oct 2011 18:54:44 -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; Fri, 07 Oct 2011 18:54:31 +0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error) Date: Fri, 07 Oct 2011 18:54:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: 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-10/txt/msg00538.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640 --- Comment #6 from Richard Guenther 2011-10-07 18:53:44 UTC --- (In reply to comment #3) > Hmm, this is not as trivial as PR50638. fortran frontend generates this > static variable local to MAIN: > > static struct __vtype_MAIN___T1 __vtab_MAIN___T1 = {._hash=41707971, ._size=4, > ._extends=0B, ._def_init=&__def_init_MAIN___T1, ._copy=__copy_MAIN___T1}; > > (the reference to &__def_init_MAIN___T1 will later cause the segfault). > __vtab_MAIN___T1 will be referenced from __vtab_MAIN___T2 (also static local > in MAIN). But __vtab_MAIN___T2 will _not_ be referenced from MAIN. > > Instead references to __vtab_MAIN___T2 and __vtab_MAIN___T1 are emitted from > function 'fun'. So far so good. The problem lies in walking DECL_INITIAL > for these statics. add_referenced_var will only walk it if > DECL_CONTEXT==current_function_decl (sensible). Nobody calls > add_rerefenced_var(__vtab_MAIN___T1) for function MAIN (sensible, as there > are no references). > > We will call add_rerefenced_var(__vtab_MAIN___T1) from function 'fun' (also > sane), which then won't walk DECL_INITIAL, i.e. nobody makes > __def_init_MAIN___T1 referenced. > > The the code in tree-ssa-live comes and walks initializers of local variables > that are used. It does so for function MAIN and variable __vtab_MAIN___T > (which is in local_decls, just not in referenced_vars), because it is marked > used (it's a non-local decl, therefore var_ann is still active from the calls > from function 'fun'). That one then walks the initializer and now notices > that nothing in it is marked referenced. > > The non-triviality here lies in deciding who's wrong: add_referenced_var > (i.e. should it always mark referenced all initializers, even though they > might come from other function contexts), the tree-ssa-live code (should > it perhaps not look into initializers or at least expect them not necessarily > marked), or in the fortran frontend (should it perhaps call add_referenced_var > also for the local static in MAIN). Huh, I don't see why tree-ssa-live would need to walk variable initializers (which generally don't exist unless for static storage duration vars).