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

Thanks Torbjorn,

I've been trying really hard to reproduce the issue. And failed so far.
I now tried to build a --target=arm-none-eabi GCC locally, but that doesn't 
compile. How do you compile it?

I fear we're currently at a point where neither of us really understand the 
problem and whether your patch is the best solution.

- Matthias

Torbjorn SVENSSON [Friday, 14 August 2026, 14:17:07 CEST]:
> 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


-- 
───────────────────────────────────────────────────────────────────
 Matthias Kretz                        https://www.kretzfamily.de/
───────────────────────────────────────────────────────────────────

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEroo/QdgfHhrjcEOni/oLaRkZhWgFAmp/NjEACgkQi/oLaRkZ
hWjClgf/R47l2GQAXe+aOxOvKMI/F60oWGuYcCfjzADRANb9fAOd/wS1ewrl9SMc
kxVEjle4b8c36fro3GD8fk0ZaSEM+6FtcFmYstMEb1JcW5fSm2jKZe+MCbTd4xoN
mRybdzrktse//jdZoV5zVeoK622AZn/SUjADjMALx4DSP/XFI7YG9Ftiwjzpidtg
0apelx3m4k99UuHjkZc/qjSAWmdPgmUDd5V74CKsqCT/EkvF3y7ecgfHjakvHb0X
sk46NdUJnvHVWU3PT2LdSMFd5O5VxfMEPuS9z9xjWjUU0fS3Bx6XBT5o/xPw0geO
OWa3irELEGYnFrAkyRPfNYnv3Zj7LA==
=fZJT
-----END PGP SIGNATURE-----