https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122762
Richard Sandiford <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |avieira at gcc dot gnu.org
--- Comment #10 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
+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.
As for why it does that, see the commit message for
g:482b2b43e5101921ad94e51e052a18b353f8a3f5, which introduced the check.
