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.
