[PATCH 0/2] alpha: enable building with clang

[PATCH 0/2] alpha: enable building with clang

[Matt Turner]

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>

[PATCH 1/2] alpha: enable building with clang

[Matt Turner]

Register the clang target triple for alpha, and pass -Wa,-mev6 only when
building with gcc.  That flag exists to stop gas emulating instructions
the assembler thinks the target lacks; it is a gas-only option, and
clang's integrated assembler does not emulate instructions in the first
place, so nothing is needed there.

With this, LLVM=1 (and LLVM_IAS=1) builds work.  Note that the alpha
backend is not in upstream LLVM yet; it lives in

  https://github.com/alphalinux-org/llvm-project

and is a work in progress.

Signed-off-by: Matt Turner <mattst88@gmail.com>
---
 arch/alpha/Makefile    | 8 +++++++-
 scripts/Makefile.clang | 1 +
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile
index 35445ff2e489..54283705911f 100644
--- a/arch/alpha/Makefile
+++ b/arch/alpha/Makefile
@@ -27,10 +27,16 @@ cpuflags-$(CONFIG_ALPHA_GENERIC)	:= -mcpu=ev56 -mtune=ev6
 cflags-y				+= $(cpuflags-y)
 
 
+KBUILD_CFLAGS += $(cflags-y)
+
 # For TSUNAMI, we must have the assembler not emulate our instructions.
 # The same is true for IRONGATE, POLARIS, PYXIS.
 # BWX is most important, but we don't really want any emulation ever.
-KBUILD_CFLAGS += $(cflags-y) -Wa,-mev6
+# Only gas emulates instructions the target does not implement, and only gas
+# understands -mev6; clang's integrated assembler never emulates.
+ifdef CONFIG_CC_IS_GCC
+KBUILD_CFLAGS += -Wa,-mev6
+endif
 
 libs-y				+= arch/alpha/lib/
 
diff --git a/scripts/Makefile.clang b/scripts/Makefile.clang
index b67636b28c35..2434cf90ad7e 100644
--- a/scripts/Makefile.clang
+++ b/scripts/Makefile.clang
@@ -1,6 +1,7 @@
 # Individual arch/{arch}/Makefiles should use -EL/-EB to set intended
 # endianness and -m32/-m64 to set word size based on Kconfigs instead of
 # relying on the target triple.
+CLANG_TARGET_FLAGS_alpha	:= alpha-linux-gnu
 CLANG_TARGET_FLAGS_arm		:= arm-linux-gnueabi
 CLANG_TARGET_FLAGS_arm64	:= aarch64-linux-gnu
 CLANG_TARGET_FLAGS_hexagon	:= hexagon-linux-musl

-- 
2.54.0

[PATCH 2/2] alpha: read $gp and $sp explicitly for clang

[Matt Turner]

clang honors a local `register unsigned long x __asm__("$N")` variable
only where it appears as an inline-asm operand; merely reading it does
not produce the contents of that register.  So trap_init() passed an
undefined global pointer to PAL_wrkgp, and load_PCB() stored an undefined
stack pointer into the PCB that swpctx then loaded.  Either one wedges an
early boot.

Read the registers explicitly instead: an inline mov for $gp in
trap_init(), and the file-scope current_stack_pointer for $sp in
load_PCB().  A file-scope register-asm variable is the form clang does
support.

Signed-off-by: Matt Turner <mattst88@gmail.com>
---
 arch/alpha/kernel/traps.c | 4 +++-
 arch/alpha/mm/init.c      | 3 +--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
index 7631129ac914..5b4f1ae2b74b 100644
--- a/arch/alpha/kernel/traps.c
+++ b/arch/alpha/kernel/traps.c
@@ -925,7 +925,9 @@ void
 trap_init(void)
 {
 	/* Tell PAL-code what global pointer we want in the kernel.  */
-	register unsigned long gptr __asm__("$29");
+	unsigned long gptr;
+
+	__asm__ volatile("mov $29, %0" : "=r"(gptr));
 	wrkgp(gptr);
 
 	wrent(entArith, 1);
diff --git a/arch/alpha/mm/init.c b/arch/alpha/mm/init.c
index 9531cbc761c0..f4d65a60c869 100644
--- a/arch/alpha/mm/init.c
+++ b/arch/alpha/mm/init.c
@@ -63,8 +63,7 @@ pgd_alloc(struct mm_struct *mm)
 static inline unsigned long
 load_PCB(struct pcb_struct *pcb)
 {
-	register unsigned long sp __asm__("$30");
-	pcb->ksp = sp;
+	pcb->ksp = (unsigned long)current_stack_pointer;
 	return __reload_thread(pcb);
 }
 

-- 
2.54.0

Re: [PATCH 0/2] alpha: enable building with clang

[Nathan Chancellor]

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

Re: [PATCH 1/2] alpha: enable building with clang

[Magnus Lindholm]

On Mon, Aug 3, 2026 at 7:08 PM Matt Turner <mattst88@gmail.com> wrote:
>
> Register the clang target triple for alpha, and pass -Wa,-mev6 only when
> building with gcc.  That flag exists to stop gas emulating instructions
> the assembler thinks the target lacks; it is a gas-only option, and
> clang's integrated assembler does not emulate instructions in the first
> place, so nothing is needed there.
>
> With this, LLVM=1 (and LLVM_IAS=1) builds work.  Note that the alpha
> backend is not in upstream LLVM yet; it lives in
>
>   https://github.com/alphalinux-org/llvm-project
>
> and is a work in progress.
>
> Signed-off-by: Matt Turner <mattst88@gmail.com>
> ---
>  arch/alpha/Makefile    | 8 +++++++-
>  scripts/Makefile.clang | 1 +
>  2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile
> index 35445ff2e489..54283705911f 100644
> --- a/arch/alpha/Makefile
> +++ b/arch/alpha/Makefile
> @@ -27,10 +27,16 @@ cpuflags-$(CONFIG_ALPHA_GENERIC)    := -mcpu=ev56 -mtune=ev6
>  cflags-y                               += $(cpuflags-y)
>
>
> +KBUILD_CFLAGS += $(cflags-y)
> +
>  # For TSUNAMI, we must have the assembler not emulate our instructions.
>  # The same is true for IRONGATE, POLARIS, PYXIS.
>  # BWX is most important, but we don't really want any emulation ever.
> -KBUILD_CFLAGS += $(cflags-y) -Wa,-mev6
> +# Only gas emulates instructions the target does not implement, and only gas
> +# understands -mev6; clang's integrated assembler never emulates.
> +ifdef CONFIG_CC_IS_GCC
> +KBUILD_CFLAGS += -Wa,-mev6
> +endif
>
>  libs-y                         += arch/alpha/lib/
>

Hi Matt,

I agree with Nathan's suggestion to leave the
CLANG_TARGET_FLAGS_alpha entry out for now and add it separately when
the Alpha backend is being upstreamed to LLVM.

Could you send a v2 containing just the arch/alpha/Makefile change?

Since -Wa,-mev6 is an assembler-specific option, I think maybe the condition
should also test the assembler rather than the compiler?

ifdef CONFIG_AS_IS_GNU
KBUILD_CFLAGS += -Wa,-mev6
endif

That preserves the option for both GCC and clang builds using GNU as,
including clang with LLVM_IAS=0, while omitting it for LLVM's integrated
assembler.

The revised Alpha Makefile patch can then go through the Alpha tree,
while the scripts/Makefile.clang change can wait until the backend is
available upstream.

Thanks,
Magnus

Re: [PATCH 2/2] alpha: read $gp and $sp explicitly for clang

[Magnus Lindholm]

Hi Matt,

On Mon, Aug 3, 2026 at 7:08 PM Matt Turner <mattst88@gmail.com> wrote:
>
> clang honors a local `register unsigned long x __asm__("$N")` variable
> only where it appears as an inline-asm operand; merely reading it does
> not produce the contents of that register.  So trap_init() passed an
> undefined global pointer to PAL_wrkgp, and load_PCB() stored an undefined
> stack pointer into the PCB that swpctx then loaded.  Either one wedges an
> early boot.
>
> Read the registers explicitly instead: an inline mov for $gp in
> trap_init(), and the file-scope current_stack_pointer for $sp in
> load_PCB().  A file-scope register-asm variable is the form clang does
> support.
>
> Signed-off-by: Matt Turner <mattst88@gmail.com>
> ---
>  arch/alpha/kernel/traps.c | 4 +++-
>  arch/alpha/mm/init.c      | 3 +--
>  2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
> index 7631129ac914..5b4f1ae2b74b 100644
> --- a/arch/alpha/kernel/traps.c
> +++ b/arch/alpha/kernel/traps.c
> @@ -925,7 +925,9 @@ void
>  trap_init(void)
>  {
>         /* Tell PAL-code what global pointer we want in the kernel.  */
> -       register unsigned long gptr __asm__("$29");
> +       unsigned long gptr;
> +
> +       __asm__ volatile("mov $29, %0" : "=r"(gptr));
>         wrkgp(gptr);
>
>         wrent(entArith, 1);
> diff --git a/arch/alpha/mm/init.c b/arch/alpha/mm/init.c
> index 9531cbc761c0..f4d65a60c869 100644
> --- a/arch/alpha/mm/init.c
> +++ b/arch/alpha/mm/init.c
> @@ -63,8 +63,7 @@ pgd_alloc(struct mm_struct *mm)
>  static inline unsigned long
>  load_PCB(struct pcb_struct *pcb)
>  {
> -       register unsigned long sp __asm__("$30");
> -       pcb->ksp = sp;
> +       pcb->ksp = (unsigned long)current_stack_pointer;
>         return __reload_thread(pcb);
>  }
>
>
> --
> 2.54.0
>

This looks good to me. The explicit $gp read and use of
current_stack_pointer avoid relying on the unsupported local
register-asm behavior.

I also built and booted the patched kernel successfully with GCC on an
AlphaStation DS10.

Reviewed-by: Magnus Lindholm linmag7@gmail.com
Tested-by: Magnus Lindholm linmag7@gmail.com

I am happy to take this through the Alpha tree.

Thanks,
Magnus

[PATCH v2 1/2] alpha: pass -Wa,-mev6 only when using GNU as

[Matt Turner]

That flag exists to stop gas emulating instructions the assembler thinks
the target lacks.  It is a gas-only option, and LLVM's integrated
assembler does not emulate instructions in the first place, so nothing
is needed there.

Condition it on CONFIG_AS_IS_GNU rather than the compiler, so it is
still passed for clang builds using GNU as (LLVM_IAS=0) and omitted only
for the integrated assembler.

Signed-off-by: Matt Turner <mattst88@gmail.com>
---
Only this patch changed; patch 2/2 ("alpha: read $gp and $sp explicitly
for clang") is unchanged from v1 and is not resent.

Changes in v2:
- Drop the scripts/Makefile.clang CLANG_TARGET_FLAGS_alpha entry.  It
  will be sent separately when the alpha backend is upstreamed to LLVM.
- Condition -Wa,-mev6 on CONFIG_AS_IS_GNU rather than CONFIG_CC_IS_GCC,
  so it is still passed for clang builds using GNU as (LLVM_IAS=0).
- Reword the subject and commit message for the reduced scope.
- Link to v1: https://lore.kernel.org/r/20260803-alpha-clang-v1-0-1c4ba5ba7a64@gmail.com

 arch/alpha/Makefile | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile
index 35445ff2e489..7074602dca94 100644
--- a/arch/alpha/Makefile
+++ b/arch/alpha/Makefile
@@ -27,10 +27,16 @@ cpuflags-$(CONFIG_ALPHA_GENERIC)	:= -mcpu=ev56 -mtune=ev6
 cflags-y				+= $(cpuflags-y)
 
 
+KBUILD_CFLAGS += $(cflags-y)
+
 # For TSUNAMI, we must have the assembler not emulate our instructions.
 # The same is true for IRONGATE, POLARIS, PYXIS.
 # BWX is most important, but we don't really want any emulation ever.
-KBUILD_CFLAGS += $(cflags-y) -Wa,-mev6
+# Only gas emulates instructions the target does not implement, and only gas
+# understands -mev6.  LLVM's integrated assembler never emulates.
+ifdef CONFIG_AS_IS_GNU
+KBUILD_CFLAGS += -Wa,-mev6
+endif
 
 libs-y				+= arch/alpha/lib/
 
-- 
2.54.0

Re: [PATCH v2 1/2] alpha: pass -Wa,-mev6 only when using GNU as

[Magnus Lindholm]

Hi Matt,

On Wed, Aug 5, 2026 at 8:56 PM Matt Turner <mattst88@gmail.com> wrote:
>
> That flag exists to stop gas emulating instructions the assembler thinks
> the target lacks.  It is a gas-only option, and LLVM's integrated
> assembler does not emulate instructions in the first place, so nothing
> is needed there.
>
> Condition it on CONFIG_AS_IS_GNU rather than the compiler, so it is
> still passed for clang builds using GNU as (LLVM_IAS=0) and omitted only
> for the integrated assembler.
>
> Signed-off-by: Matt Turner <mattst88@gmail.com>
> ---
> Only this patch changed; patch 2/2 ("alpha: read $gp and $sp explicitly
> for clang") is unchanged from v1 and is not resent.
>
> Changes in v2:
> - Drop the scripts/Makefile.clang CLANG_TARGET_FLAGS_alpha entry.  It
>   will be sent separately when the alpha backend is upstreamed to LLVM.
> - Condition -Wa,-mev6 on CONFIG_AS_IS_GNU rather than CONFIG_CC_IS_GCC,
>   so it is still passed for clang builds using GNU as (LLVM_IAS=0).
> - Reword the subject and commit message for the reduced scope.
> - Link to v1: https://lore.kernel.org/r/20260803-alpha-clang-v1-0-1c4ba5ba7a64@gmail.com
>
>  arch/alpha/Makefile | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile
> index 35445ff2e489..7074602dca94 100644
> --- a/arch/alpha/Makefile
> +++ b/arch/alpha/Makefile
> @@ -27,10 +27,16 @@ cpuflags-$(CONFIG_ALPHA_GENERIC)    := -mcpu=ev56 -mtune=ev6
>  cflags-y                               += $(cpuflags-y)
>
>
> +KBUILD_CFLAGS += $(cflags-y)
> +
>  # For TSUNAMI, we must have the assembler not emulate our instructions.
>  # The same is true for IRONGATE, POLARIS, PYXIS.
>  # BWX is most important, but we don't really want any emulation ever.
> -KBUILD_CFLAGS += $(cflags-y) -Wa,-mev6
> +# Only gas emulates instructions the target does not implement, and only gas
> +# understands -mev6.  LLVM's integrated assembler never emulates.
> +ifdef CONFIG_AS_IS_GNU
> +KBUILD_CFLAGS += -Wa,-mev6
> +endif
>
>  libs-y                         += arch/alpha/lib/
>>
>  arch/alpha/Makefile | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile
> index 35445ff2e489..7074602dca94 100644
> --- a/arch/alpha/Makefile
> +++ b/arch/alpha/Makefile
> @@ -27,10 +27,16 @@ cpuflags-$(CONFIG_ALPHA_GENERIC)    := -mcpu=ev56 -mtune=ev6
>  cflags-y                               += $(cpuflags-y)
>
>
> +KBUILD_CFLAGS += $(cflags-y)
> +
>  # For TSUNAMI, we must have the assembler not emulate our instructions.
>  # The same is true for IRONGATE, POLARIS, PYXIS.
>  # BWX is most important, but we don't really want any emulation ever.
> -KBUILD_CFLAGS += $(cflags-y) -Wa,-mev6
> +# Only gas emulates instructions the target does not implement, and only gas
> +# understands -mev6.  LLVM's integrated assembler never emulates.
> +ifdef CONFIG_AS_IS_GNU
> +KBUILD_CFLAGS += -Wa,-mev6
> +endif
>
>  libs-y                         += arch/alpha/lib/
>

Thanks for the update. This looks good to me.

Reviewed-by: Magnus Lindholm linmag7@gmail.com

Thanks,
Magnus

Re: [PATCH 2/2] alpha: read $gp and $sp explicitly for clang

[Maciej W. Rozycki]

On Mon, 3 Aug 2026, Magnus Lindholm wrote:

> > diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
> > index 7631129ac914..5b4f1ae2b74b 100644
> > --- a/arch/alpha/kernel/traps.c
> > +++ b/arch/alpha/kernel/traps.c
> > @@ -925,7 +925,9 @@ void
> >  trap_init(void)
> >  {
> >         /* Tell PAL-code what global pointer we want in the kernel.  */
> > -       register unsigned long gptr __asm__("$29");
> > +       unsigned long gptr;
> > +
> > +       __asm__ volatile("mov $29, %0" : "=r"(gptr));
> >         wrkgp(gptr);
> >
> >         wrent(entArith, 1);
> 
> This looks good to me. The explicit $gp read and use of
> current_stack_pointer avoid relying on the unsupported local
> register-asm behavior.

 It could have been worth mentioning in the change description that no 
code quality regression results here with GCC:

--- arch/alpha/kernel/traps-0.dump	2026-08-11 11:57:59.895247441 +0100
+++ arch/alpha/kernel/traps-1.dump	2026-08-11 11:56:31.788713285 +0100
@@ -2223,8 +2223,8 @@
 			1b70: GPDISP	.text+0x4
     1b74:	00 00 bd 23 	lda	gp,0(gp)
     1b78:	f0 ff de 23 	lda	sp,-16(sp)
-    1b7c:	10 04 fd 47 	mov	gp,a0
-    1b80:	00 00 5e b7 	stq	ra,0(sp)
+    1b7c:	00 00 5e b7 	stq	ra,0(sp)
+    1b80:	10 04 fd 47 	mov	gp,a0
     1b84:	37 00 00 00 	call_pal	0x37
     1b88:	04 00 00 c2 	br	a0,1b9c <trap_init+0x2c>
     1b8c:	08 00 1e a6 	ldq	a0,8(sp)

 Also I think our coding style would rather see the asm written as:

	__asm__ __volatile__("mov $29, %0" : "=r" (gptr));

 Otherwise:

Reviewed-by: Maciej W. Rozycki <macro@orcam.me.uk>

  Maciej

Re: [PATCH 2/2] alpha: read $gp and $sp explicitly for clang

[Magnus Lindholm]

On Tue, Aug 11, 2026 at 1:10 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
> On Mon, 3 Aug 2026, Magnus Lindholm wrote:
>
> > > diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
> > > index 7631129ac914..5b4f1ae2b74b 100644
> > > --- a/arch/alpha/kernel/traps.c
> > > +++ b/arch/alpha/kernel/traps.c
> > > @@ -925,7 +925,9 @@ void
> > >  trap_init(void)
> > >  {
> > >         /* Tell PAL-code what global pointer we want in the kernel.  */
> > > -       register unsigned long gptr __asm__("$29");
> > > +       unsigned long gptr;
> > > +
> > > +       __asm__ volatile("mov $29, %0" : "=r"(gptr));
> > >         wrkgp(gptr);
> > >
> > >         wrent(entArith, 1);
> >
> > This looks good to me. The explicit $gp read and use of
> > current_stack_pointer avoid relying on the unsupported local
> > register-asm behavior.
>
>  It could have been worth mentioning in the change description that no
> code quality regression results here with GCC:
>
> --- arch/alpha/kernel/traps-0.dump      2026-08-11 11:57:59.895247441 +0100
> +++ arch/alpha/kernel/traps-1.dump      2026-08-11 11:56:31.788713285 +0100
> @@ -2223,8 +2223,8 @@
>                         1b70: GPDISP    .text+0x4
>      1b74:      00 00 bd 23     lda     gp,0(gp)
>      1b78:      f0 ff de 23     lda     sp,-16(sp)
> -    1b7c:      10 04 fd 47     mov     gp,a0
> -    1b80:      00 00 5e b7     stq     ra,0(sp)
> +    1b7c:      00 00 5e b7     stq     ra,0(sp)
> +    1b80:      10 04 fd 47     mov     gp,a0
>      1b84:      37 00 00 00     call_pal        0x37
>      1b88:      04 00 00 c2     br      a0,1b9c <trap_init+0x2c>
>      1b8c:      08 00 1e a6     ldq     a0,8(sp)
>
>  Also I think our coding style would rather see the asm written as:
>
>         __asm__ __volatile__("mov $29, %0" : "=r" (gptr));
>
>  Otherwise:
>
> Reviewed-by: Maciej W. Rozycki <macro@orcam.me.uk>
>
>   Maciej

Hi Matt,

Given Maciej's comment on the inline asm style, do you want to send a v2
of this patch, or are you happy for me to fold the

__asm__ volatile(...)

to

__asm__ __volatile__(...)

style change in when I apply it to the Alpha tree?

Either is fine with me.

Thanks,
Magnus

Re: [PATCH 2/2] alpha: read $gp and $sp explicitly for clang

[Matt Turner]

On Tue, Aug 11, 2026 at 1:55 PM Magnus Lindholm <linmag7@gmail.com> wrote:
>
> On Tue, Aug 11, 2026 at 1:10 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
> >
> > On Mon, 3 Aug 2026, Magnus Lindholm wrote:
> >
> > > > diff --git a/arch/alpha/kernel/traps.c b/arch/alpha/kernel/traps.c
> > > > index 7631129ac914..5b4f1ae2b74b 100644
> > > > --- a/arch/alpha/kernel/traps.c
> > > > +++ b/arch/alpha/kernel/traps.c
> > > > @@ -925,7 +925,9 @@ void
> > > >  trap_init(void)
> > > >  {
> > > >         /* Tell PAL-code what global pointer we want in the kernel.  */
> > > > -       register unsigned long gptr __asm__("$29");
> > > > +       unsigned long gptr;
> > > > +
> > > > +       __asm__ volatile("mov $29, %0" : "=r"(gptr));
> > > >         wrkgp(gptr);
> > > >
> > > >         wrent(entArith, 1);
> > >
> > > This looks good to me. The explicit $gp read and use of
> > > current_stack_pointer avoid relying on the unsupported local
> > > register-asm behavior.
> >
> >  It could have been worth mentioning in the change description that no
> > code quality regression results here with GCC:
> >
> > --- arch/alpha/kernel/traps-0.dump      2026-08-11 11:57:59.895247441 +0100
> > +++ arch/alpha/kernel/traps-1.dump      2026-08-11 11:56:31.788713285 +0100
> > @@ -2223,8 +2223,8 @@
> >                         1b70: GPDISP    .text+0x4
> >      1b74:      00 00 bd 23     lda     gp,0(gp)
> >      1b78:      f0 ff de 23     lda     sp,-16(sp)
> > -    1b7c:      10 04 fd 47     mov     gp,a0
> > -    1b80:      00 00 5e b7     stq     ra,0(sp)
> > +    1b7c:      00 00 5e b7     stq     ra,0(sp)
> > +    1b80:      10 04 fd 47     mov     gp,a0
> >      1b84:      37 00 00 00     call_pal        0x37
> >      1b88:      04 00 00 c2     br      a0,1b9c <trap_init+0x2c>
> >      1b8c:      08 00 1e a6     ldq     a0,8(sp)
> >
> >  Also I think our coding style would rather see the asm written as:
> >
> >         __asm__ __volatile__("mov $29, %0" : "=r" (gptr));
> >
> >  Otherwise:
> >
> > Reviewed-by: Maciej W. Rozycki <macro@orcam.me.uk>
> >
> >   Maciej
>
> Hi Matt,
>
> Given Maciej's comment on the inline asm style, do you want to send a v2
> of this patch, or are you happy for me to fold the
>
> __asm__ volatile(...)
>
> to
>
> __asm__ __volatile__(...)
>
> style change in when I apply it to the Alpha tree?
>
> Either is fine with me.
>
> Thanks,
> Magnus

Hey Magnus,

Feel free to just fix it up when you apply it.

Thanks,
Matt

Re: [PATCH 2/2] alpha: read $gp and $sp explicitly for clang

[Maciej W. Rozycki]

On Tue, 11 Aug 2026, Magnus Lindholm wrote:

> >  Also I think our coding style would rather see the asm written as:
> >
> >         __asm__ __volatile__("mov $29, %0" : "=r" (gptr));
> 
> Given Maciej's comment on the inline asm style, do you want to send a v2
> of this patch, or are you happy for me to fold the
> 
> __asm__ volatile(...)
> 
> to
> 
> __asm__ __volatile__(...)
> 
> style change in when I apply it to the Alpha tree?

 FAOD it's also the space in `"=r" (gptr)'.

  Maciej

Re: [PATCH 2/2] alpha: read $gp and $sp explicitly for clang

[Magnus Lindholm]

On Tue, Aug 11, 2026 at 11:56 PM Maciej W. Rozycki <macro@orcam.me.uk> wrote:
>
>  FAOD it's also the space in `"=r" (gptr)'.
>
>   Maciej

Done!

Magnus

Re: [PATCH 0/2] alpha: enable building with clang

[Nick Desaulniers]

+ 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

Re: [PATCH 0/2] alpha: enable building with clang

[Matt Turner]

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.

Re: [PATCH 0/2] alpha: enable building with clang

[Nick Desaulniers]

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

Re: [PATCH 0/2] alpha: enable building with clang

[Maciej W. Rozycki]

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

Re: [PATCH 0/2] alpha: enable building with clang

[Matt Turner]

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.

Re: [PATCH 0/2] alpha: enable building with clang

[David Laight]

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