I believe that upstream is mistaken. It is not safe to allow other memory accesses to be speculated into the ldrex/strex region, and (at least on Cortex A9/A15) the only way to prevent that is to issue full memory barriers before and after. Arguably the compiler should be allowed to move memory accesses across the whole block, but that seems like a small optimization (compared to the memory barrier overhead), and I have seen no benchmark data to support it. I don't know whether GCC's later optimization passes can be relied upon not to move opcodes into the critical region if the "memory" attribute on the assembly block were omitted.
See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48126, which suggests a fix to GCC's compare-and-swap intrinsics to prevent them from skipping the trailing memory barrier. ** Bug watch added: GCC Bugzilla #48126 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48126 -- You received this bug notification because you are a member of Kubuntu Bugs, which is subscribed to qt4-x11 in ubuntu. https://bugs.launchpad.net/bugs/490371 Title: Atomic operations not safe for ARMv7,Thumb-2 and multicore -- kubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
