https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
Bug ID: 80640 Summary: Missing memory side effect Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nico...@morey-chaisemartin.com Target Milestone: --- I found what seems to be a GCC issue while building/running the OpenMPI 2.1.0 testsuite using GCC 6.3.1 on i586 (Suse Tumbleweed) I attached the tarball with the preprocessed source file and the minimum libraries. It compiles with: -------- gcc -o opal_fifo opal_fifo.c libopen-pal.so.20 -ldl libsupport.a -lrt -lm -lutil -pthread -Wl,-rpath -Wl,$(pwd) -------- When compiling witrh O0, or O1 the test works. It stalls with O2 and O3. From what I could find, the program get stuck here: -------- while (&fifo->opal_fifo_ghost == item->opal_list_next) { opal_atomic_rmb (); } -------- opal_atomic_rmb is defined like this -------- static inline void opal_atomic_rmb(void) { __atomic_thread_fence (2); } -------- The assembly for this loop looks like this: -------- => 0x080495a5 <+325>: cmp %edi,%eax 0x080495a7 <+327>: je 0x80495a5 <thread_test+325> -------- I'm a little rusty on x86 assembly but for me it means GCC cached the value to compare and never reloads them from memory. I would expect the __atomic_thread_fence atomic to have some kind of memory side effect that means these values should be reloaded. Adding a simple -------- __asm__ __volatile__("": : :"memory"); -------- to opal_atomic_rmb seems to fix the issue.