[llvm-dev] __c11_atomic builtins' input requirements

[Alex Brachet-Mialot via llvm-dev]

Have you posted this on the libcxx-dev list? You might have more luck there.

On Sat, Jan 4, 2020 at 11:10 AM Ben Trapani via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Any update on this? What are your thoughts?
>
> On Sat, Dec 28, 2019 at 8:23 PM Ben Trapani <ben.trapani1995 at gmail.com>
> wrote:
>
>> I have started working on an implementation of atomic_ref. Implementing
>> this requires performing atomic operations on arbitrary references. The
>> behavior is undefined if a reference is provided that is not aligned per
>> the public export required_alignment. What assumptions do the __c11_atomic
>> builtins make about destination argument alignment, format, size etc.? Is
>> it required that the destination argument be annotated as _Atomic like the
>> corresponding standard c11 functions require?
>>
>> The following code in libcxx/include/config implies that the c11 atomic
>> builtins should be substituted for gcc atomic builtins if present:
>>
>> #if __has_feature(cxx_atomic) || __has_extension(c_atomic) ||
>> __has_keyword(_Atomic)
>> #  define _LIBCPP_HAS_C_ATOMIC_IMP
>>
>> #elif defined(_LIBCPP_COMPILER_GCC)
>>
>> #  define _LIBCPP_HAS_GCC_ATOMIC_IMP
>>
>> #endif
>>
>> To implement atomic_ref, it might be cleaner to use the gcc builtins. By
>> doing so, we avoid depending on the internals of the c11 atomic builtins.
>> The required alignment of referenced variables would always be the first
>> power of 2 >= max(type_size, type_alignment). Alternatively, we could use
>> the c11 atomic builtins when available if it is enough to require that the
>> input reference is aligned as the atomic type would be. What are your
>> thoughts?
>>
>> Regards,
>> Ben
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200104/021a6b2a/attachment.html>