https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122762
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Richard Sandiford from comment #10) > +Andre since this is about SIMD clones. > > (In reply to Richard Biener from comment #8) > > simd_clone_adjust_sve_vector_type does > > > > 30276 /* ??? This creates anonymous "SVE type" attributes for all types, > > 30277 even those that correspond to <arm_sve.h> types. This affects > > type > > 30278 compatibility in C/C++, but not in gimple. (Gimple type > > equivalence > > 30279 is instead decided by TARGET_COMPATIBLE_VECTOR_TYPES_P.) > > 30280 > > (gdb) > > 30281 Thus a C/C++ definition of the implementation function will > > have a > > 30282 different function type from the declaration that this code > > creates. > > 30283 However, it doesn't seem worth trying to fix that until we have > > a > > 30284 way of handling implementations that operate on unpacked types. > > */ > > 30285 type = build_distinct_type_copy (type); > > 30286 aarch64_sve::add_sve_type_attribute (type, num_zr, num_pr, NULL, > > NULL); > > > > but at least the comment about GIMPLE type compatibility is wrong. > > Why do you say that it's wrong? AIUI (going only from the description) the > ICE is caused by the fact that gimple (useless_type_conversion_p) does check > TARGET_COMPATIBLE_VECTOR_TYPES_P. The comment says it does _not_ affect gimple type compatibility. Then of course follows to say that's decided with that hook, but that hook checks presence of the SVE type attribute. > > As for why it does that, see the commit message for > g:482b2b43e5101921ad94e51e052a18b353f8a3f5, which introduced the check. Hm, but that talks about argument passing / return ABIs? useless_type_conversion_p applies to value types, at most its check for FUNCTION_TYPE compatibility would need to use this check?
