[Bug lto/52178] [4.7 regression] Ada bootstrap failure in LTO mode

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-13 11:34:46 UTC ---
(In reply to comment #2)
> > 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?)
> 
> The Ada front-end doesn't touch TYPE_CANONICAL at all.  It's the same type, but
> instantiated from different units.  What I don't understand is when type
> merging is supposed to be done: WPA, LTRANS, or both?

Merging happens at WPA time, it happens again at LTRANS but that is an
implementation artifact (it should not be necessary to merge again).

> > Unless the COMPONENT_REF in question comes from constant folding from
> > a global variable initializer for example (which is what the ??? is about)?
> 
> No, it's in a simple assignment statement.
> 
> > So - at which point during the compilation does the verification issue
> > happen?
> 
> See the opening message, it's LTRANS.  The type mismatch is already present
> when the assignment statement is streamed in at the beginning of LTRANS, as the
> streamed in FIELD_DECL isn't the original FIELD_DECL that was streamed out.

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).

So - do you by chance happen to have a (small) testcase? ;)

I suppose I can try lto-bootstrapping with Ada myself, let's see if I can
find time to do so.