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.
