[llvm-bugs] [Bug 47188] New: __atomic_load_8 assumes 8 byte alignment

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=47188

            Bug ID: 47188
           Summary: __atomic_load_8 assumes 8 byte alignment
           Product: compiler-rt
           Version: 11.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: builtins
          Assignee: unassignedbugs at nondot.org
          Reporter: tijl at coosemans.org
                CC: llvm-bugs at lists.llvm.org

For the following code (found in Glasgow Haskell Compiler), clang generates a
function call to __atomic_load_8 on x86 (32-bit) because long long is 8 bytes
in size but only 4 byte aligned:

long long test( long long *x ) {
  return( __atomic_load_n( x, __ATOMIC_SEQ_CST ));
}

For 8 byte aligned types clang uses the FILDLL instruction, which (according to
the Intel SDM Vol 3) loads 8 bytes atomically as long as they don't cross a
cache line boundary, which is guaranteed when they are 8 byte aligned but not
with 4 byte alignment.

The problem now is that libcompiler_rt casts the argument of __atomic_load_8 to
an _Atomic( long long ) pointer which has 8 byte alignment so clang uses the
FILDLL instruction when compiling libcompiler_rt.

I don't know if the bug is in libcompiler_rt or in clang.  Maybe
__atomic_load_n should only accept atomic types like __c11_atomic_load does.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200816/76a59918/attachment.html>