[llvm-dev] __c11_atomic builtins' input requirements

Alex Brachet-Mialot via llvm-dev llvm-dev at lists.llvm.org
Sat Jan 4 09:55:52 PST 2020

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)
>> #elif defined(_LIBCPP_COMPILER_GCC)
>> #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>

More information about the llvm-dev mailing list