Re: [PATCH 0/2] alpha: enable building with clang
Nathan Chancellor <[email protected]> Mon, 3 Aug 2026 12:51:35 -0700
| Newsgroups | org.kernel.vger.linux-kbuild,dev.linux.lists.llvm,org.kernel.vger.linux-alpha,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <20260803195135.GA1083357@ax162> |
Hi Matt,
On Mon, Aug 03, 2026 at 01:08:40PM -0400, Matt Turner wrote:
> Two small patches to let the alpha kernel build with clang.
Nice!
> The first registers the clang target triple and stops passing -Wa,-mev6
> when the compiler is not gcc. That flag exists to keep gas from emulating
> instructions it believes the target lacks; it is a gas-only option and
> clang's integrated assembler does not emulate instructions, so it is not
> needed there.
>
> The second fixes two uses of local register-asm variables that clang does
> not honor. clang treats `register unsigned long x __asm__("$N")` as the
> named register only where the variable appears as an inline-asm operand,
> so reading one to get the live $gp or $sp yields an undefined value.
> trap_init() passed that to PAL_wrkgp and load_PCB() stored it into the
> PCB for swpctx, either of which wedges an early boot.
>
> Note that the alpha backend is not in upstream LLVM. It lives in
>
> https://github.com/alphalinux-org/llvm-project
>
> and is a work in progress, so the scripts/Makefile.clang entry has no
> effect with an upstream clang today. I am sending this now because the
> second patch is a real bug in its own right -- the register-asm reads are
> only guaranteed to work by gcc's implementation, not by anything either
> compiler documents -- but I understand if the kbuild side would rather
> wait for the backend to land upstream.
Yeah, I am not sure how I feel taking the target triple part of the
first patch. On the one hand, I want it to be easy for you to test
against upstream Linux but on the other, I do not want people to read
this Makefile and assume that ARCH=alpha will work with an upstream
clang.
We could add a comment that the backend is currently out of tree but
that would go stale once it is actually upstream and it will be floating
around for forever. Maybe a better compromise is taking arch/alpha
changes now then landing the scripts/Makefile.clang change when you
actually start upstreaming the backend, as being able to use an upstream
version of clang should be relatively imminent at that point.
--
Cheers,
Nathan