https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122981
--- Comment #6 from Torbjorn SVENSSON <azoff at gcc dot gnu.org> --- I think I have an answer to the "why would arm-linux-gnueabihf support this type" question. I used AI to compare a build of arm-none-eabi with a build of arm-none-linux-gnueabihf and it came up with this: > The failure is a libstdc++ <experimental/simd> NEON bug caused by differing > canonical 32-bit types: > > arm-none-linux-gnueabihf defines int32_t as int. arm-none-eabi defines > int32_t > as long int. simd_neon.h creates a __vector(2) int, then passes it to > vpadd_s32, which expects int32x2_t. On Linux those are the same vector type; > on > arm-none-eabi, int32x2_t is based on long int, so they are distinct and the > call is rejected. > > The actual fix belongs in simd_neon.h:332: convert or bit-cast the > intermediate > vector to the ACLE-required int32x2_t type before calling vpadd_s32. The > implementation must not assume that a four-byte integer selected via > sizeof(int) is the same type as int32_t. So, based on that response, I'd say that the fix that I've suggested in comment 2 is wrong and the proper fix is, as was mentioned in comment 4, to add a cast somewhere. The two binary distributions of GCC that I used to compare can be found here: https://gitlab.arm.com/tooling/gnu-toolchains-for-arm/-/tree/releases/15.3.rel1
