[PATCH 0/4] Get rid of all NEON intrinsics stdint.h type hacks

Nathan Chancellor nathan at kernel.org
Thu Oct 29 14:41:05 PDT 2026


Hi Ard,

On Thu, Oct 29, 2026 at 02:50:20PM +0100, Ard Biesheuvel wrote:
> Recent Clang has become more finicky when it comes to overriding the
> type macros that the freestanding stdint.h consumes when defining the
> uintXX_t types, and so it is time to finally get rid of this entirely.

Just as information for other folks:

  https://github.com/llvm/llvm-project/pull/227722#issuecomment-6065215071

> So instead of making stdint.h (which comes from the compiler when
> -ffreestanding is set on the command line) agree with the kernel's
> linux/types.h header, avoid the latter entirely in the compilation units
> that actually use the NEON intrinsics (which are always leaf functions
> that are not tightly coupled to kernel APIs).

I had not even considered this as an option, thanks a lot for exploring
it and sending this series as a result. I definitely think this is the
preferred route forward based on my discussions with clang folks
upstream since they were quite unhappy with stdint.h being overridden in
this manner.

> Note that the disagreements are about long vs. long long on arm64, and
> long vs. int on 32-bit ARM, so never about types that actually have
> conflicting representations.
> 
> Ard Biesheuvel (4):
>   lib/crc: Don't include <linux/types.h> in NEON intrinsics code
>   xor: arm/arm64: Move NEON xor_gen() dispatch into the glue code
>   arm64: Drop stdint.h type overrides from asm/neon-intrinsics.h
>   ARM: Drop stdint.h type overrides from asm/neon-intrinsics.h

This passes my arm and arm64 test matrix with LLVM 23.1.4 and a version
of LLVM 24 with the breaking change mentioned above. This will be needed
in stable but I don't mind taking a look at the backports when the time
comes.

Tested-by: Nathan Chancellor <nathan at kernel.org>

-- 
Cheers,
Nathan



More information about the linux-arm-kernel mailing list