https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #2)
> (In reply to Kewen Lin from comment #1)
> > IMHO this is an omission when we were adding supports for opaque type, const
> > __vector_quad and __vector_quad should be taken as
> > canonical_types_compatible.
> >
> > I wonder if we can simply take it just like what it handles for
> > "Non-aggregate types", for example:
> >
> > diff --git a/gcc/tree.cc b/gcc/tree.cc
> > index 2f488e4467c..555e96c59d5 100644
> > --- a/gcc/tree.cc
> > +++ b/gcc/tree.cc
> > @@ -13510,6 +13510,7 @@ gimple_canonical_types_compatible_p (const_tree t1,
> > const_tree t2,
> > || TREE_CODE (t1) == VECTOR_TYPE
> > || TREE_CODE (t1) == COMPLEX_TYPE
> > || TREE_CODE (t1) == OFFSET_TYPE
> > + || TREE_CODE (t1) == OPAQUE_TYPE
> > || POINTER_TYPE_P (t1))
> > {
> > /* Can't be the same type if they have different recision. */
> >
> > Or adding one default hook which does the similar thing, and then if one
> > target needs some target specific checks on its opaque type, one specific
> > hook can be provided.
>
> I'm quoting tree.def, emphasis mine:
>
> /* This is for types that will use MODE_OPAQUE in the back end. They are
> meant
> to be able to go in a register of some sort but are _EXPLICITLY NOT TO BE
> CONVERTED_ or operated on like INTEGER_TYPE. They will have size and
> alignment information only. */
> DEFTREECODE (OPAQUE_TYPE, "opaque_type", tcc_type, 0)
>
Good point! My fault, I didn't read through this documentation. It seems to say
no conversions are allowed on it? (either explicit or implicit?)
> so why should we care about special-casing them? The target should have set
> TYPE_CANONICAL appropriately if necessary, why didn't it? Btw, 'const'
> qualification should go into the type variant chain (well, for "normal"
> types), where TYPE_MAIN_VARIANT is the unqualified type variant.
> TYPE_CANONICAL
> shouldn't come into play here.
>
With flag_checking on, while doing lto_fixup_state, verify_type will check
every tree type, it further checks with verify_type_variant, then fails with
gimple_canonical_types_compatible_p (t, tv, false). (here trust_type_canonical
is false).
I think this is a common issue for any cv-qualified opaque type when lto
checking is on.
In this case,
t1:
const __vector_quad
t2:
__vector_quad
Both TYPE_MAIN_VARIANT and both TYPE_CANONICAL is exactly the same here (all
equivalent to t2).
> Btw, the whole idea of "opaque" is a hack and it seems to backfire now?
Not sure, it had some adjustments with r11-5222 before, I thought we need some
similar for this issue.
