Thread (37 messages) 37 messages, 7 authors, 2026-02-19

Re: [PATCH v3 3/3] arm64, compiler-context-analysis: Permit alias analysis through __READ_ONCE() with CONFIG_LTO=y

From: Will Deacon <will@kernel.org>
Date: 2026-02-04 14:15:58
Also in: lkml, llvm

On Wed, Feb 04, 2026 at 02:14:00PM +0100, Peter Zijlstra wrote:
On Wed, Feb 04, 2026 at 11:46:02AM +0100, Marco Elver wrote:
quoted
On Tue, 3 Feb 2026 at 12:47, Will Deacon [off-list ref] wrote:
[...]
quoted
quoted
quoted
What does GCC do with this? :/
GCC currently doesn't see it, LTO is clang only.
LTO is just one way that a compiler could end up breaking dependency
chains, so I really want to maintain the option to enable this path for
GCC in case we run into problems caused by other optimisations in future.
It will work for GCC, but only from GCC 11. Before that __auto_type
does not drop qualifiers:
https://godbolt.org/z/sc5bcnzKd (switch to GCC 11 to see it compile)

So to summarize, all supported Clang versions deal with __auto_type
correctly for the fallback; GCC from version 11 does (kernel currently
supports GCC 8 and above). From GCC 14 and Clang 19 we have
__typeof_unqual__.

I really don't see another way forward; there's no other good way to
solve this issue. I would advise against pessimizing new compilers and
features because maybe one day we might still want to enable this
version of READ_ONCE() for GCC 8-10.

Should we one day choose to enable this READ_ONCE() version for GCC,
we will (a) either have bumped the minimum GCC version to 11+, or (b)
we can only do so from GCC 11. At this point GCC 11 was released 5
years ago!
There is, from this thread:

  https://lkml.kernel.org/r/20260111182010.GH3634291@ZenIV

another trick to strip qualifiers:

  #define unqual_non_array(T) __typeof__(((T(*)(void))0)())

which will work from GCC-8.4 onwards. Arguably, it should be possible to
raise the minimum from 8 to 8.4 (IMO).
That sounds reasonable to me but I'm not usually the one to push back
on raising the minimum compiler version!
But yes; in general I think it is fine to have 'old' compilers generate
suboptimal code.
I'm absolutely fine with the codegen being terrible for ancient
toolchains as long as it's correct.

Will
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help