https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111623
Bug ID: 111623
Summary: __sync_synchronize compiler barrier not honored (rv64)
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rehn at rivosinc dot com
Target Milestone: ---
Hi,
In openjdk rv64 port we see code moved over __sync_synchronize, only one case
found.
We have:
__synch_synchronize()
__atomic_compare_exchange(...)
__synch_synchronize()
We see additional code moved between those two fences:
ld a4,0(a1)
lw a2,8(a1)
fence
sub a5,s6,a4
srl a5,a5,a2
sext.w a5,a5
beqz s1,1d0 <.L1^B143> // <=== should not be here ?
sub a4,s1,a4
srl a4,a4,a2
lr.w a2,(s2)
bne a2,a4,8a <.L1^B142> // a4 not sign extended ?
sc.w a0,a5,(s2)
bnez a0,7c <.L1^B141>
sext.w a5,a2
fence
We notice this because the the compare value was not sign extended. (4 byte
cmpxchg)
While looking at how that could be, we notice additional code in this critical
section.
Compare value loaded with ld but never sign extended before lr.w/sc.w.
Fixing the code motions issue by addition a explicit compiler barrier (volatile
asm memory clobber), or by using __atomic_thread_fence(__ATOMIC_SEQ_CST)
instead: both issues goes away.
If there is two bugs, or one bugs causing collateral effects we don't know.
I don't have a simple reproducer, and seems very specific.
The templated code is expanded for every garbage collector, and only one GC see
this issue. (even if there is some kind bad code there, compiler barrier should
still be respected IMHO)
openjdk bug: https://bugs.openjdk.org/browse/JDK-8316566
issue that found this: https://github.com/openjdk/jdk/pull/15715
code to reproduce: https://github.com/robehn/jdk/tree/for-gcc-sync/ (sorry
again for no simpler way)
gcc 12/13 do not have this issue, it seems to be in 11 and 10 at least.
Due to limit on attachments:
https://github.com/robehn/jdk/tree/for-gcc-sync/gcc-bug-info
(contains the unsafe.ii, command line, and additional snippets)
No clue which component this should be, but c++ front end is most likely wrong
:)
Thanks, Robbin
