Hi Jeff,
Thank you very much! Yes, as Kito also mentioned, I admit that it's weird and
unclear to me why this test fails with LMUL8 while LMUL1/LMUL4 passed. I can
try to investigate it and see what the root cause really is.
Best,
Luke Zhuang
------------------------------------------------------------------
From:Jeffrey Law <[email protected]>
Send Time:Sun, Jul 19, 2026, 04:28
To:Luke Zhuang<[email protected]>;
"gcc-patches"<[email protected]>
CC:"kito.cheng"<[email protected]>; "rdapp.gcc"<[email protected]>;
palmer<[email protected]>; andrew<[email protected]>;
"jim.wilson.gcc"<[email protected]>;
"juzhe.zhong"<[email protected]>; rdsandiford<[email protected]>;
"zhuangzhi.zz"<[email protected]>; Kito Cheng<[email protected]>
Subject:Re: [PATCH] RISC-V: Fix the LRA crashing triggered by TLSDESC clobber
updates
On 7/15/2026 8:34 AM, Luke Zhuang wrote:
> From: "Luke Zhuang" <[email protected]>
>
> An LRA crashing is found by fuzz-testing, and is triggered by
> <0748d2c83fc>. We can avoid it by replacing RVVM8QI with RVVM1QI,
> and may need to fix the LRA later.
>
> A reduced test is appended as well, demonstrating the crash.
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.md (@tlsdesc<mode>): Use individual
> RVVM1QI clobbers instead of four RVVM8QI.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/tlsdesc_clobber_lra.c: New test.
>
> Co-authored-by: Kito Cheng <[email protected]>
Thanks. We can go with this version, though I strongly suspect the real
bug is in LRA; though it's not immediately obvious what. I wouldn't
expect that function to need spilling or vector register usage in
general, so it's unclear why is LRA is unhappy or why LRA works when you
break the clobbers down into their components. Interestingly enough
using LMUL4 clobbers works as well which cuts the clobber set to just 8
entries instead of 32.
Anyway, I'll push it momentarily.
jeff