From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2410 invoked by alias); 13 Feb 2012 11:58:01 -0000 Received: (qmail 2396 invoked by uid 22791); 13 Feb 2012 11:58:01 -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; Mon, 13 Feb 2012 11:57:48 +0000 From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/52178] [4.7 regression] Ada bootstrap failure in LTO mode Date: Mon, 13 Feb 2012 11:58: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: rguenther at suse dot de 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: 2012-02/txt/msg01284.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178 --- Comment #5 from rguenther at suse dot de 2012-02-13 11:57:43 UTC --- On Mon, 13 Feb 2012, ebotcazou at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178 > > --- Comment #4 from Eric Botcazou 2012-02-13 11:53:38 UTC --- > > Merging happens at WPA time, it happens again at LTRANS but that is an > > implementation artifact (it should not be necessary to merge again). > > OK. > > > Ok, this sounds like it is a real bug, especially if the existing machinery > > to plug these holes does not trigger (and issue the warning). > > Something I remarked while trying to debug this: "regular" type merging has a > sophisticated machinery taking into account SCCs (gtc_visit) while "canonical" > type merging doesn't have it. The hypothesis I came up with is that the former > was able to merge the various instances of the type whereas the latter wasn't. > Since the middle-end type system is based on canonical types, it chokes. The good thing about the "canonical" type merging machinery is that it does not need one! It merges structurally equivalent types (thus considers all pointers equal). So, if "canonical" type merging does _not_ merge sth that the "regular" type merging merges then that's a bug (in which part remains to be identified ...). > > So - do you by chance happen to have a (small) testcase? ;) > > No, but I can try to distill one I'm LTO bootstrapping Ada now, let's see if I can figure out sth quickly (well, I doubt that ... ;)) Sth I'm not very familiar is the QUAL_UNION record kinds - maybe you can eye the two merging machineries for obvious errors here? Richard.