This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/59767] New: __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59767

            Bug ID: 59767
           Summary: __atomic_load_n with __ATOMIC_SEQ_CST should result in
                    a memory barrier
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mikulas at artax dot karlin.mff.cuni.cz
              Host: x86_64-unknown-linux-gnu
            Target: x86_64-unknown-linux-gnu
             Build: x86_64-unknown-linux-gnu

The following function:
int f(void)
{
        int x;
        return __atomic_load_n(&x, __ATOMIC_SEQ_CST);
}
results in this code when compiled with -O2:
f:
.LFB0:
        .cfi_startproc
        movl    -4(%rsp), %eax
        ret
        .cfi_endproc
.LFE0:

The flag "__ATOMIC_SEQ_CST" should imply a full memory barrier before and after
the operation, but there is no barrier in the generated code.

The bug also exists in 32-bit mode and in x32 mode.

You should place a "mfence" instruction before the movl instruction that loads
the value.

I believe that it is not necessary to place the mfence instruction after the
memory load, but you should better check the ia32 specification for that.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]