[Bug middle-end/106833] Miss to handle OPAQUE_TYPE specially in verify_type

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #10)
> (In reply to Segher Boessenkool from comment #9)
> > Although, preferably we should not allow assigning one opaque type to another
> > opaque type just because they will eventually use the same mode, not without
> > warning anyway?  Or is that unavoidable?  Compare assigning a V4SI to a V4SF.
> 
> IIUC, you meant the assignment happening for two different opaque types,
> then it's a conversion?

Yes exactly.

> If so, I think we can check it in
> rs6000_invalid_conversion, currently it just simply checks the modes.

Yup.

> If we
> have two different opaque types mapping to one same mode, we can further
> check if the things like TYPE_CANONICAL match.

Like that.  It isn't urgent -- we currently have only one type for each of
our two opaque modes -- but if we allow too much here, we would need a separate
mode for each opaque thing we want to distinguish, which is contrary to the
point of having it :-)

> > I don't know if your patch does this, btw, and it isn't so easy to test, we
> > currently have only one type for each of our opaque modes.  Maybe test by
> > adding an extra builtin type :-)
> 
> This patch doesn't handle that, the main issue here is that some
> cv-qualified opaque type can cause ICE in type verification during LTO.
> IMHO, opaque types conversion issue looks like a separated issue and it can
> be handled in target hook invalid_conversion. But I guess you want a more
> generic check?  And as you pointed out, there is no such scenario that two
> opaque types have the same mode, not sure if we really want to handle it for
> now. :-)

I think it can be handled generically, no target code is needed for it.