https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726
--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> --- (In reply to rsand...@gcc.gnu.org from comment #4) > (In reply to Jakub Jelinek from comment #3) > > But if they mangle differently, then structural_comptypes shouldn't treat > > them as same types. Definitely. > That certainly avoids the ICE, and makes GCC's behaviour consistent > with Clang for things like: > > typedef float vecf __attribute__((vector_size(16))); > vecf x; > float32x4_t &y = x; > > Previously we accepted this, with the struct_comptypes change > we reject it (like Clang does). But that might break existing > code, so I'm not sure it would be backportable. If necessary we could add a conversion between the pointer-to-vector types. > I guess the question then is: what does TYPE_STRUCTURAL_EQUALITY_P > mean for VECTOR_TYPEs in the context of structural_comptypes? The same thing it means for any other type: setting TYPE_CANONICAL properly is too hard, so use structural_comptypes. > And (if this is a different question) what case is that function's > VECTOR_TYPE handling for? I.e. when do we want to return true for > a pair of VECTOR_TYPEs whose TYPE_MAIN_VARIANTs are different? We want to return true if they should be considered the same type. Generally, TYPE_MAIN_VARIANT isn't sufficient for checking type identity, as it only looks through variants of the outermost type: If I have typedef int myint; typedef myint* myintptr; taking TYPE_MAIN_VARIANT of myintptr gives myint*, not int*. That's why TYPE_CANONICAL was introduced, so we didn't need to do structural comparison whenever we wanted to compare types.
