Jan Wassenberg

hm, strange. Is there something about the AWS config that causes compilers built there to be configured for only that CPU? The above godbolt does work as expected also for...

Thanks, gcc-11.4 is a different issue. That compiler is too old to know about SVE2 and we should not be attempting to use it. I will update Highway to fix...

Sounds like progress :) I think [support was added](https://sourceware.org/pipermail/binutils-cvs/2019-May/050836.html) for that in GAS in 2019. Upgrading binutils sounds good!

I think this is now resolved, please reopen if not :)

For the record, my suggestion to change hwy::bfloat16_t to a typedef will break ABI compatibility, so let's not do that :) But I like your idea of adding a ctor...

Thanks for reporting the issue. Looks like AES related tests, and the NEON target indeed includes AES instructions. I see from the A64FX microarchitecture guide that AESD/AESE etc are supported....

Thanks for confirming. Interesting, it does seem to be an AES instruction that is faulting. It is possible that AES instructions are disabled/trapped by the OS? Does /proc/cpuinfo mention "aes"?

Interesting, thanks for confirming. Indeed we are detecting that the CPU supports AES, according to the OS, via this code in targets.cc: ``` const CapBits hw = getauxval(AT_HWCAP); #if HWY_ARCH_ARM_A64...

Thanks for adding the printfs! I see that we only add HWY_NEON to HWY_BASELINE_NEON if the compiler sets __ARM_FEATURE_AES, which looks correct. As to why the printf is skipped: we...

A quick update, we are getting close to enabling runtime dispatch for aarch64+clang, which would fix that. Per the output you provided above, we are correctly detecting that the system...