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
