Two small patches to let the alpha kernel build with clang.

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.

---
Matt Turner (2):
      alpha: enable building with clang
      alpha: read $gp and $sp explicitly for clang

 arch/alpha/Makefile       | 8 +++++++-
 arch/alpha/kernel/traps.c | 4 +++-
 arch/alpha/mm/init.c      | 3 +--
 scripts/Makefile.clang    | 1 +
 4 files changed, 12 insertions(+), 4 deletions(-)
---
base-commit: 0e6be1d34ae92e2b0dbc1b7410d422b22464389a
change-id: 20260803-alpha-clang-6acd144eb86c

Best regards,
-- 
Matt Turner <mattst88@gmail.com>

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

+ John Paul

On Mon, Aug 3, 2026 at 12:51 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> 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.

Right. It's cool you have something building. I'm curious if the
resulting image boots? (That's the next major milestone).

I'm curious, since we've yet to have such a case of an out of tree
llvm backend, what's your plan, if any, to upstream your backend in
llvm-project proper? Perhaps as an experimental backend?  We have bugs
filed in our issue track for m68k which is experimental (but upstream)
in LLVM.

>
> 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



--
Thanks,
~Nick Desaulniers

On Mon, Aug 17, 2026 at 7:16 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> + John Paul
>
> On Mon, Aug 3, 2026 at 12:51 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > 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.
>
> Right. It's cool you have something building. I'm curious if the
> resulting image boots? (That's the next major milestone).
>
> I'm curious, since we've yet to have such a case of an out of tree
> llvm backend, what's your plan, if any, to upstream your backend in
> llvm-project proper? Perhaps as an experimental backend?  We have bugs
> filed in our issue track for m68k which is experimental (but upstream)
> in LLVM.

It builds a kernel that boots in qemu and on real hardware.

As of two days ago, it's capable of building itself and the 373
packages of a Gentoo stage3 + a few other things. These include glibc
and other core components (in a qemu-backend container on a fast
multicore amd64 system).

I would very much prefer to have the backend upstream, and I plan to
start a discussion on discourse.llvm.org this week. I think an
experimental backend is probably the limit of what makes sense for
Alpha?

If you have advice on going about this, I would welcome it (privately
or in reply to this thread).

Current diffstat is

461 files changed, 29735 insertions(+), 88 deletions(-)

of which {llvm,lld,clang}/test is

266 files changed, 9871 insertions(+), 4 deletions(-)

Currently reviewing and cleaning up, so the numbers will change.

On Mon, Aug 17, 2026 at 8:28 PM Matt Turner <mattst88@gmail.com> wrote:
>
> On Mon, Aug 17, 2026 at 7:16 PM Nick Desaulniers
> <ndesaulniers@google.com> wrote:
> >
> > >
> > > On Mon, Aug 03, 2026 at 01:08:40PM -0400, Matt Turner wrote:
> > > > Two small patches to let the alpha kernel build with clang.
> > >
> > I'm curious, since we've yet to have such a case of an out of tree
> > llvm backend, what's your plan, if any, to upstream your backend in
> > llvm-project proper? Perhaps as an experimental backend?  We have bugs
> > filed in our issue track for m68k which is experimental (but upstream)
> > in LLVM.
>
> It builds a kernel that boots in qemu and on real hardware.

Wild.  Where did you even get real hardware? I know very little about Alpha.

>
> As of two days ago, it's capable of building itself and the 373
> packages of a Gentoo stage3 + a few other things. These include glibc
> and other core components (in a qemu-backend container on a fast
> multicore amd64 system).

I haven't kept up with Adhemerval's work on building glibc with clang,
but pretty wild to hear about glibc building with clang period, for
alpha no less.

>
> I would very much prefer to have the backend upstream, and I plan to
> start a discussion on discourse.llvm.org this week. I think an
> experimental backend is probably the limit of what makes sense for
> Alpha?

I agree. An RFC on discourse is the way to go. I'd use m68k as an example.

>
> If you have advice on going about this, I would welcome it (privately
> or in reply to this thread).
>
> Current diffstat is
>
> 461 files changed, 29735 insertions(+), 88 deletions(-)

Only advice is that if any of that was AI generated, please do take
the time to review LLVM's AI policy.  Reviewers have been getting
crunched by low quality AI commits recently, and are a bit salty all
around.

https://llvm.org/docs/AIToolPolicy.html

>
> of which {llvm,lld,clang}/test is
>
> 266 files changed, 9871 insertions(+), 4 deletions(-)
>
> Currently reviewing and cleaning up, so the numbers will change.



-- 
Thanks,
~Nick Desaulniers

On Tue, 18 Aug 2026 09:24:37 -0700
Nick Desaulniers <ndesaulniers@google.com> wrote:

...
> Wild.  Where did you even get real hardware? I know very little about Alpha.

There are two PC-case size alpha in my garage.
They have PCI, 64bit PCI and ISA expansion slots.
I'd guess they are 25-30 years old and are hardly used.
Both worked last time I tried to boot them, but the scsi disks have
stuck bearings.

They are close to going to the tip, but could be free to a good home!

	David

On Tue, Aug 18, 2026 at 12:24 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Mon, Aug 17, 2026 at 8:28 PM Matt Turner <mattst88@gmail.com> wrote:
> >
> > On Mon, Aug 17, 2026 at 7:16 PM Nick Desaulniers
> > <ndesaulniers@google.com> wrote:
> > >
> > > >
> > > > On Mon, Aug 03, 2026 at 01:08:40PM -0400, Matt Turner wrote:
> > > > > Two small patches to let the alpha kernel build with clang.
> > > >
> > > I'm curious, since we've yet to have such a case of an out of tree
> > > llvm backend, what's your plan, if any, to upstream your backend in
> > > llvm-project proper? Perhaps as an experimental backend?  We have bugs
> > > filed in our issue track for m68k which is experimental (but upstream)
> > > in LLVM.
> >
> > It builds a kernel that boots in qemu and on real hardware.
>
> Wild.  Where did you even get real hardware? I know very little about Alpha.

Mostly eBay :)

... along with most of my other pet computers (https://mattst88.com/computers/)

> >
> > As of two days ago, it's capable of building itself and the 373
> > packages of a Gentoo stage3 + a few other things. These include glibc
> > and other core components (in a qemu-backend container on a fast
> > multicore amd64 system).
>
> I haven't kept up with Adhemerval's work on building glibc with clang,
> but pretty wild to hear about glibc building with clang period, for
> alpha no less.

What a time to be alive!

> >
> > I would very much prefer to have the backend upstream, and I plan to
> > start a discussion on discourse.llvm.org this week. I think an
> > experimental backend is probably the limit of what makes sense for
> > Alpha?
>
> I agree. An RFC on discourse is the way to go. I'd use m68k as an example.

Thank you. I'll find the m68k discussion and model mine on that
(assuming they were successful).

> >
> > If you have advice on going about this, I would welcome it (privately
> > or in reply to this thread).
> >
> > Current diffstat is
> >
> > 461 files changed, 29735 insertions(+), 88 deletions(-)
>
> Only advice is that if any of that was AI generated, please do take
> the time to review LLVM's AI policy.  Reviewers have been getting
> crunched by low quality AI commits recently, and are a bit salty all
> around.
>
> https://llvm.org/docs/AIToolPolicy.html

Indeed, I have been, but my goal is to do enough self-review such that
no one would be able to tell that an LLM was involved. I will of
course disclose that LLMs were used.

On Tue, 18 Aug 2026, Nick Desaulniers wrote:

> > It builds a kernel that boots in qemu and on real hardware.
> 
> Wild.  Where did you even get real hardware? I know very little about Alpha.

 Of course Matt has hardware, he's been an Alpha/Linux port maintainer for 
some 16 years now!  And several of us have some too.  I've got mine since 
2005, and previously ran and worked on Alpha/Linux as early as back in 
1998 while the port was still supported by DEC (and the company existed in 
the first place).

  Maciej