https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114130
Bug ID: 114130
Summary: RISC-V: `__atomic_compare_exchange` does not use
sign-extended value
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: x at maxxsoft dot net
Target Milestone: ---
GCC 13.2 does not generate sign-extension for value to be compared with the
result of `lr.w` instruction in `__atomic_compare_exchange`:
https://godbolt.org/z/nafKhPa1Y
Code:
```
void foo(uint32_t *p) {
uintptr_t x = *(uintptr_t *)p;
uint32_t e = !p ? 0 : (uintptr_t)p >> 1;
uint32_t d = (uintptr_t)x;
__atomic_compare_exchange(p, &e, &d, 0, __ATOMIC_RELAXED,
__ATOMIC_RELAXED);
}
```
Assembly generated by `gcc -O3`:
```
foo:
ld a4,0(a0)
srli a5,a0,1
1: lr.w a3,0(a0); bne a3,a5,1f; sc.w a2,a4,0(a0); bnez a2,1b; 1:
ret
```
Which `a5` should be sign-extended, since the RISC-V ISA manual says `lr.w`
returns a sign-extended value in RV64.
But `gcc -O3 -fno-delete-null-pointer-checks` generates correct code:
```
foo:
ld a4,0(a0)
li a5,0
beq a0,zero,.L2
srli a5,a0,1
sext.w a5,a5
.L2:
1: lr.w a3,0(a0); bne a3,a5,1f; sc.w a2,a4,0(a0); bnez a2,1b; 1:
ret
```
`gcc -O3 -fno-tree-ter`'s output is slight different, but also sign-extended.
`clang -O3` always generates correct code:
```
foo: # @foo
lw a1, 0(a0)
srli a2, a0, 1
sext.w a2, a2
.LBB0_1: # =>This Inner Loop Header: Depth=1
lr.w a3, (a0)
bne a3, a2, .LBB0_3
sc.w a4, a1, (a0)
bnez a4, .LBB0_1
.LBB0_3:
ret
```
