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/ ───────────────────────────────────────────────────────────────────
signature.asc
Description: This is a digitally signed message part.
