From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31939 invoked by alias); 10 Jan 2012 15:51:04 -0000 Received: (qmail 31930 invoked by uid 22791); 10 Jan 2012 15:51:03 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_CB 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; Tue, 10 Jan 2012 15:50:50 +0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/51809] [4.7 Regression][OOP] ICE (segfault) depending on USE statements order Date: Tue, 10 Jan 2012 15:51:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P4 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: 2012-01/txt/msg01040.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51809 --- Comment #2 from Tobias Burnus 2012-01-10 15:49:52 UTC --- Some debugging. To make it easier, I split the test case into two files and I look at the one which only consists of "module merry_ICE". The ICE occurs for writing the .mod file of module merry_ICE. However, the actual issue already occurs with reading. If one sets a break point in mio_symbol, one sees that GCC reads the following symbols: $1 = 0x2aaaacbf01e0 "__vtab_foo_Foo_t" $2 = 0x2aaaacbf01c8 "__def_init_foo_Foo_t" $3 = 0x2aaaacbf0258 "__vtab_bar_Bar_t" $4 = 0x2aaaacbf0240 "__def_init_bar_Bar_t" The issue is for the PARAMETER "__vtab_bar_Bar_t": its initializer (sym->value) is a structure constructor consisting of _hash, _size, _extends etc. However, during read in the _extends gets only a c->expr->symtree == NULL. Thus, during write out, it crashes in mio_symtree_ref as that tries to access symtree->n.sym. If one reverts the order of the USE statements, one first reads the __vtab of "bar" - again with symtree == NULL - and only then one reads __vtab of "foo". Seemingly, only if the order is reversed the symtree fixing (fixup/pointer_info) works. The main change of the patch in comment 1 is that it changes FL_VARIABLE to FL_PARAMETER. If one looks at mio_symbol, one sees: if (sym->attr.flavor == FL_PARAMETER) mio_expr (&sym->value); One possibility is to revert the patch of comment 1 - and use the other variant to set TREE_READONLY: http://gcc.gnu.org/ml/fortran/2011-11/msg00099.html Alternatively - or additionally [as it can also affect other code] - one should find out why the symtree is not fixed up.