From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10804 invoked by alias); 8 Feb 2012 21:37:35 -0000 Received: (qmail 10651 invoked by uid 22791); 8 Feb 2012 21:37:34 -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, 08 Feb 2012 21:37:21 +0000 From: "ebotcazou at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/52178] New: [4.7 regression] Ada bootstrap failure in LTO mode Date: Wed, 08 Feb 2012 21:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new 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: ebotcazou 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: --- X-Bugzilla-Changed-Fields: Message-ID: 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/msg00905.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178 Bug #: 52178 Summary: [4.7 regression] Ada bootstrap failure in LTO mode Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: lto AssignedTo: unassigned@gcc.gnu.org ReportedBy: ebotcazou@gcc.gnu.org Build: x86_64-*-linux 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'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!