https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
--- Comment #6 from Nicolas Morey-Chaisemartin
---
Ok. So there's something wrong :)
I'll make a work around for SUSE while waiting for a fix in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
--- Comment #5 from Alexander Monakov ---
I think the bug is that on x86 __atomic_thread_fence(x) is expanded into
nothing for x!=__ATOMIC_SEQ_CST, it should place a compiler barrier similar to
expansion of __atomic_signal_fence.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
--- Comment #4 from Nicolas Morey-Chaisemartin
---
I agree the volatile shoud fix thing> I'll have to see with the ompi guys to
fix that.
But shouldn't __atomic_thread_fence () have a side effect here and force the
memory to be reloaded ?
If it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
Alexander Monakov changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
--- Comment #2 from Nicolas Morey-Chaisemartin
---
Created attachment 41325
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41325&action=edit
Test case
Previous tarball was too big. I stripped all debug info from the lib and it
should work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80640
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
