http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
--- Comment #5 from rguenther at suse dot de <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 <ebotcazou at gcc dot gnu.org> 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.
