Re: [PATCH] libstdc++: arm: convert vpadd_* operands to intrinsic types [PR122981]

Hi Matthias,

I do not know much about vectorization or neon. I just happened to see the
failure in my arm-none-eabi tests and asked AI what the error message is
about. It suggested that wrapping the input arguments with "__to_intrin"
calls to get a compatible data type.
As you probably saw in the compiler explorer link, I am using armv7-a and not
the armv8-a. Don't know how much that matters, but it's at least one difference.

On 2026-08-14 13:40, Matthias Kretz wrote:
> Torbjorn SVENSSON [Friday, 14 August 2026, 12:19:11 CEST]:
>>> I'm fairly certain that the code worked at some point. Actually, a quick
>>> test on Compiler Explorer and I can't reproduce the issue. But I must
>>> admit that I'm lost to all the variants of ARM, and I'm probably not
>>> testing the one that fails for you.
>>>
>>> Can you show me how to compile https://compiler-explorer.com/z/jWPEPTo8a
>>> so that it requires the cast to intrinsic type?
>>
>> First of all, the toolchain that you select is a linux based and it has
>> different rules than arm-none-eabi.
>> Regardless, the problem happens when the GNU vector has different size than
>> what NEON can work with.
>>
>> In your example at https://compiler-explorer.com/z/jWPEPTo8a, simply change
>> to
>>
>> using V [[gnu::vector_size(4)]] = signed char;
> 
> But that's impossible in the code you changed. E.g. for your first change in
> simd_neon.h sizeof(__x) == 16 and sizeof(_Tp) == 1. Also __lo64 is guaranteed
> to return a sizeof 8 vector. Consequently, the failure you're resolving
> happens with
> 
>    using V [[gnu::vector_size(8)]] = signed char;
> 
> The issue must be that the intrinsic rejects GNU vector types, which it
> doesn't reject consistently. Is it correct to summarize the issue as: ARM
> intrinsics require ARM vector types and GNU vector types are *sometimes / not
> always* implicitly convertible to ARM vector types?

It might be that I wrap too many locations. It's been a while since I wrote the
patch, but to my memory, the test case that I wrote required all the locations
to be updated to work correctly.

> If that's the case, then shouldn't we modify *all* NEON intrinsics calls to
> use __to_intrin?

Sorry, don't know. :S
> And more confusion on the ARM NEON API: vpadd_s8 returns an ARM vector type,
> which happily implicitly converts to GNU vector type?

Could be the case. I honestly know too little to state anything here.
> I guess I'm trying to find out whether this is an issue that is better fixed
> in the compiler rather than worked around in the library. Because it seems to
> be inconsistent and user hostile to me.
> 
> - Matthias
> 


Kind regards,
Torbjörn