https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 5 Sep 2022, linkw at gcc dot gnu.org wrote: > 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). Ah, that special "mode". I think verify_types shouldn't do anything for OPAQUE_TYPES or alternatively trust the targets setup of TYPE_MAIN_VARIANT/TYPE_CANONICAL. Maybe verify TYPE_CANONICAL and TYPE_MAIN_VARIANT are also OPAQUE_TYPE. So the solution should be fully inside verify_type. > 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.
