On 10/17/25 17:01, Jeff Law wrote: > > On 10/15/25 8:29 AM, Aleksa Paunovic wrote: >> From: Chao-ying Fu <[email protected]> >> >> Generate proper offset for operands in atomic_compare_and_swap on RISC-V >> big-endian targets. >> >> Signed-off-by: Aleksa Paunovic <[email protected]> >> >> gcc/ChangeLog: >> >> * config/riscv/sync.md: Calculate proper offset for big-endian. >> --- >> gcc/config/riscv/sync.md | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/gcc/config/riscv/sync.md b/gcc/config/riscv/sync.md >> index 37f15d816..8ccdbe8fb 100644 >> --- a/gcc/config/riscv/sync.md >> +++ b/gcc/config/riscv/sync.md >> @@ -605,7 +605,8 @@ (define_expand "atomic_compare_and_swap<mode>" >> value is sign-extended. */ >> rtx tmp0 = gen_reg_rtx (word_mode); >> emit_insn (gen_extend_insn (tmp0, operands[3], word_mode, >> <MODE>mode, 0)); >> - operands[3] = gen_lowpart (<MODE>mode, tmp0); >> + poly_int64 offset = BYTES_BIG_ENDIAN ? GET_MODE_SIZE (<MODE>mode) : 0; >> + operands[3] = simplify_gen_subreg (<MODE>mode, tmp0, word_mode, >> offset); > But doesn't gen_lowpart handle the endianness correction on the subreg > byte (via subreg_size_lowpart_offset)? Basically it's unclear what > you're really fixing here and there's no testcase. > > Jeff > Hello Jeff,
Thank you for your comments. I apologize for taking so much time to reply, we were trying get the gdb-sim changes upstream to make reproducing the bug easier for everyone. I go into more detail about the fixes in v2 of the series, which can be found below: https://gcc.gnu.org/pipermail/gcc-patches/2026-January/705789.html Best regards, Aleksa Paunovic
