[Bug middle-end/106833] Handle OPAQUE_TYPE in gimple_canonical_types_compatible_p

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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)

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.

Btw, the whole idea of "opaque" is a hack and it seems to backfire now?