Re: [PATCH v2] alpha: enable gnu-indirect-function support for alpha-linux

On 8/9/2026 5:59 PM, Matt Turner wrote:
> Enable __attribute__((ifunc)) for alpha*-*-linux*, which sets
> HAVE_GNU_INDIRECT_FUNCTION=1 and makes targetm.has_ifunc_p() return
> true.
>
> No Alpha backend changes are needed -- the generic ifunc machinery in
> varasm.cc handles emission, and alpha/elf.h already provides the
> required ASM_OUTPUT_TYPE_DIRECTIVE and ASM_OUTPUT_DEF macros.
>
> Rather than defaulting default_gnu_indirect_function to yes in
> config.gcc, this follows the riscv*-*-linux* precedent and gates the
> default on a toolchain feature test.  A plain assembler test would not
> be meaningful: %gnu_indirect_function is handled by generic ELF code in
> gas and has been accepted for every target for many years.  The real
> dependency is on the linker emitting R_ALPHA_IRELATIVE, so the test
> assembles, links and inspects the relocations with readelf.  Without it
> the link silently succeeds while producing an ordinary R_ALPHA_JMP_SLOT.
>
> The existing riscv test is generalized to select the expected relocation
> name per target so both share one code path.  Alpha needs its own test
> source because alpha gas reserves .set for setting assembler modes, so
> the alias is spelled with '=', matching the target's ASM_OUTPUT_DEF.
>
> Runtime support additionally requires a glibc dynamic linker that
> handles the new relocation.
>
> gcc/ChangeLog:
>
> 	* configure.ac (gcc_cv_irelative_reloc): New variable, set for
> 	riscv*-*-linux* and alpha*-*-linux*.  Perform the linker
> 	IRELATIVE check once, driven by it.
> 	* configure: Regenerate.
THanks.  I've pushed this to the trunk.

It's not great that we have a hard to test dependency on a newer glibc, 
but I don't see a good way to avoid that.  In fact, I strongly suspect 
my tester will likely fall over.  It builds and installs binutils first, 
so it's going to find assembler/linker support for ifuncs and enable 
them in GCC as a result.  But the glibc installed in the docker 
container is fairly old at this point (2.33).  We shall see by this time 
next week :-)

I doubt many folks are building new versions of GCC on alphas, so 
hopefully the pain isn't too bad.

jeff