From: Nathan Chancellor <nathan@kernel.org>
To: Ard Biesheuvel <ardb+git@google.com>
Cc: linux-kbuild@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-crypto@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
Christoph Hellwig <hch@lst.de>,
Eric Biggers <ebiggers@kernel.org>
Subject: Re: [PATCH 0/4] Get rid of all NEON intrinsics stdint.h type hacks
Date: Thu, 29 Oct 2026 14:41:05 -0700 [thread overview]
Message-ID: <20261029214105.GA44297@ax162> (raw)
In-Reply-To: <20261029135020.272082-6-ardb+git@google.com>
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@kernel.org>
--
Cheers,
Nathan
prev parent reply other threads:[~2026-10-29 21:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 13:50 [PATCH 0/4] Get rid of all NEON intrinsics stdint.h type hacks Ard Biesheuvel
2026-10-29 13:50 ` [PATCH 1/4] lib/crc: Don't include <linux/types.h> in NEON intrinsics code Ard Biesheuvel
2026-10-29 13:50 ` [PATCH 2/4] xor: arm/arm64: Move NEON xor_gen() dispatch into the glue code Ard Biesheuvel
2026-10-29 13:50 ` [PATCH 3/4] arm64: Drop stdint.h type overrides from asm/neon-intrinsics.h Ard Biesheuvel
2026-10-29 13:50 ` [PATCH 4/4] ARM: " Ard Biesheuvel
2026-10-29 21:41 ` Nathan Chancellor [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261029214105.GA44297@ax162 \
--to=nathan@kernel.org \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=ebiggers@kernel.org \
--cc=hch@lst.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox