[llvm-bugs] [Bug 30581] Inconsistent value of ATOMIC_LLONG_LOCK_FREE vs __atomic_always_lock_free(sizeof(long long), 0) on 32-bit x86

[via llvm-bugs]

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

Michał Górny <mgorny at gentoo.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Michał Górny <mgorny at gentoo.org> ---
commit 266cb72185242313c85a9f33dc33944da8b2b403
Author: Michal Gorny <mgorny at gentoo.org>
Date:   Mon Jan 9 21:54:20 2017

    [Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin

    Correct the logic used to set ATOMIC_*_LOCK_FREE preprocessor macros not
    to rely on the ABI alignment of types. Instead, just assume all those
    types are aligned correctly by default since clang uses safe alignment
    for _Atomic types even if the underlying types are aligned to a lower
    boundary by default.

    For example, the 'long long' and 'double' types on x86 are aligned to
    32-bit boundary by default. However, '_Atomic long long' and '_Atomic
    double' are aligned to 64-bit boundary, therefore satisfying
    the requirements of lock-free atomic operations.

    This fixes PR #19355 by correcting the value of
    __GCC_ATOMIC_LLONG_LOCK_FREE on x86, and therefore also fixing
    the assumption made in libc++ tests. This also fixes PR #30581 by
    applying a consistent logic between the functions used to implement
    both interfaces.

    Differential Revision: https://reviews.llvm.org/D28213

    git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291477
91177308-0d34-0410-b5e6-96231b3b80d8

-- 
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/20170110/ba777c0a/attachment.html>