http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52178
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |4.7.0
--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-10
15:09:38 UTC ---
(In reply to comment #0)
> 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 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?)
> 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!
The code is mostly to paper over invalid-code issues and to give some
sensible warning to users if they declare decls with mismatching types.
But the code should also silence all tree checking errors that are
remaining (but issue a warning, so with -Werror it would not help you).
Unless the COMPONENT_REF in question comes from constant folding from
a global variable initializer for example (which is what the ??? is about)?
So - at which point during the compilation does the verification issue
happen?
