[Bug libstdc++/122981] pr109261_constexpr_simd.cc and pr115454_find_last_set.cc fail on arm-none-eabi

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