Re: [PATCH] MIPS: Fix genex.S build with LLVM before 21

[Maciej W. Rozycki]

On Wed, 4 Nov 2026, Tzu-Ching Yang wrote:

> Wrap both expressions in %lo(). For that operator, LLVM 17 to 20
> emit a LO16 fixup instead of rejecting the operand, and resolve it when
> writing the object, since both expressions are constants by then; no
> relocation is left. Both values are between 2 and 30, so %lo() does
> not change them. 

 Seems fair.

>   - The objects are byte-identical before and after with GCC, with
>     LLVM_IAS=0 and with LLVM 21 to 23. The only exception is the
>     microMIPS ADDIU above. The 4-byte move with LLVM_IAS=0 is harmless:
>     set_vi_handler() computes the offsets and the length of the vectored
>     handler from symbols before copying it, and ejtag_debug_handler and
>     nmi_handler are only referenced through their symbols.

 I would be tempted to accept the GAS microMIPS code size regression as a 
missed optimisation.  This is a general issue with forward references and 
%lo() calculation is only one example: we're missing microMIPS relaxation 
for 16-bit vs 32-bit instruction encodings, except for branches.  We only 
do it for MIPS16 code.

> - The malta kernels built with GCC 8.1 and 16.2, LLVM 17, 20 and 23, and
>   LLVM 17 with LLVM_IAS=0 boot under QEMU 6.2 -cpu 24Kf. That CPU uses
>   r4k_wait(), so interrupts go through skipover_handle_int. Each kernel
>   boots to an init that keeps the CPU going in and out of idle and then
>   reboots; a QEMU trace shows every interrupt that lands in the idle
>   region resuming at r4k_wait_exit. A microMIPS kernel does not boot
>   under QEMU -cpu M14Kc with or without this patch, so the microMIPS
>   change was not run.

 I wouldn't be surprised with a microMIPS kernel not booting.  Support was 
messy right from the beginning and despite my opposition it was merged as 
it stood.  Maybe one of the fragile assumptions broke here or there.  Or 
it could be a QEMU emulation bug too; it doesn't seem too stable compared 
to actual hardware, microMIPS or not.  I could try bisecting it sometime 
as I do have an otherwise working microMIPS QEMU setup; sadly no actual 
microMIPS hardware.

> On 6.18.y, which also allows LLVM 15 and 16, the patch applies after
> 2b6d718c8dbe, and LLVM 15 and 16 fail and are fixed the same way.
> 
> The 56651128e2fb backport was dropped from the 6.14, 6.12 and 6.6
> stable queues because of this build failure [1], so 6.12.y and 6.6.y
> still lack that fix.

 Shouldn't this use:

Cc: <stable@xxxxxxxxxxxxxxx> # 6.6.x: 56651128e2fb: MIPS: Fix idle VS timer enqueue
Cc: <stable@xxxxxxxxxxxxxxx> # 6.6.x: 2b6d718c8dbe: MIPS: Fix whitespace damage in r4k_wait from VS timer fix
Cc: <stable@xxxxxxxxxxxxxxx> # 6.6.x

then to get this all picked up?  Or is it unsupported annotation syntax 
where a prerequisite matches a Fixes: tag?

  Maciej