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