https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515
--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Stam Markianos-Wright <stamm...@gcc.gnu.org>: https://gcc.gnu.org/g:8a1360e72d6c6056606aa5edd8c906c50f26de59 commit r13-5200-g8a1360e72d6c6056606aa5edd8c906c50f26de59 Author: Stam Markianos-Wright <stam.markianos-wri...@arm.com> Date: Mon Jan 16 11:40:40 2023 +0000 arm: Split up MVE _Generic associations to prevent type clashes [PR107515] With these previous patches: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606586.html https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606587.html we enabled the MVE overloaded _Generic associations to handle more scalar types, however at PR 107515 we found a new regression that wasn't detected in our testing: With glibc's posix/types.h: ``` typedef signed int __int32_t; ... typedef __int32_t int32_t; ``` We would get a `error: '_Generic' specifies two compatible types` from `__ARM_mve_coerce3` because of `type: param`, when `type` is `int` and `int32_t: param` both being the same under the hood. The same did not happen with Newlib's header sys/_stdint.h: ``` typedef long int __int32_t; ... typedef __int32_t int32_t ; ``` which worked fine, because it uses `long int`. The same could feasibly happen in `__ARM_mve_coerce2` between `__fp16` and `float16_t`. The solution here is to break the _Generic down so that the similar types don't appear at the same level, as is done in `__ARM_mve_typeid` gcc/ChangeLog: PR target/96795 PR target/107515 * config/arm/arm_mve.h (__ARM_mve_coerce2): Split types. (__ARM_mve_coerce3): Likewise. gcc/testsuite/ChangeLog: PR target/96795 PR target/107515 * gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-fp.c: New test. * gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-int.c: New test.
