From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3168 invoked by alias); 10 Feb 2012 15:10:06 -0000 Received: (qmail 3148 invoked by uid 22791); 10 Feb 2012 15:10:04 -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, 10 Feb 2012 15:09:41 +0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/52178] [4.7 regression] Ada bootstrap failure in LTO mode Date: Fri, 10 Feb 2012 15:10:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Keywords: ice-on-valid-code 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: Target Milestone 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-02/txt/msg01074.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178 Richard Guenther changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |4.7.0 --- Comment #1 from Richard Guenther 2012-02-10 15:09:38 UTC --- (In reply to comment #0) > The problem has been present for months despite the various LTO changes. > > The typical error message issued during LTRANS is: > > /home/eric/svn/gcc/gcc/ada/lib-load.adb: In function 'lib__load__load_unit': > /home/eric/svn/gcc/gcc/ada/lib-load.adb:344:0: error: type mismatch in > component reference > atree__atree_private_part__node_record___is_extension___XVN > > atree__atree_private_part__node_record___is_extension___XVN > > # VUSE <.MEM_328> > T142b_492 = > *atree__atree_private_part__nodes__table.19_489[D.105830_491].is_extension___XVN.S0.sloc; > > It's a type mismatch between a COMPONENT_REF and the FIELD_DECL (operand #1). > Everything is OK during compilation and the problem is apparently already there > when LTRANS kicks in, so the problem is probably in WPA. As far as I can see, > it merges 2 equivalent types and then updates the cache (uniquify_nodes): > > /* If we're going to replace an element which we'd > still visit in the next iterations, we wouldn't > handle it, so do it here. We do have to handle it > even though the field_decl itself will be removed, > as it could refer to e.g. integer_cst which we > wouldn't reach via any other way, hence they > (and their type) would stay uncollected. */ > /* ??? We should rather make sure to replace all > references to f2 with f1. That means handling > COMPONENT_REFs and CONSTRUCTOR elements in > lto_fixup_types and special-case the field-decl > operand handling. */ > if (ix < i) > lto_fixup_types (f2); > streamer_tree_cache_insert_at (cache, f1, ix); > > But, while the types of the old set and the new set of fields are compatible in > GIMPLE, there is at least one field for which the type isn't compatible in the > middle-end sense, and the type verifier chokes. I don't understand this sentence completely - if the types have been merged then the COMPONENT_REFs should have been updated, too (do they only have "weak" matched types at the point of LTO streaming? Thus, do they maybe depend on the frontend TYPE_CANONICAL setting?) > I'm a little at a loss as to how this is supposed to work: should the type of > the COMPONENT_REF be updated too, i.e is that the ??? above? Should this be > handled via TYPE_CANONICAL, i.e the old and new type must have the same? Or > should this be patched up in input_gimple_stmt, similarly to what is already > done: > /* Fixup FIELD_DECLs in COMPONENT_REFs, they are not handled > by decl merging. */ > if (TREE_CODE (op) == ADDR_EXPR) > op = TREE_OPERAND (op, 0); > while (handled_component_p (op)) > > Any hint is welcome! The code is mostly to paper over invalid-code issues and to give some sensible warning to users if they declare decls with mismatching types. But the code should also silence all tree checking errors that are remaining (but issue a warning, so with -Werror it would not help you). Unless the COMPONENT_REF in question comes from constant folding from a global variable initializer for example (which is what the ??? is about)? So - at which point during the compilation does the verification issue happen?