[cfe-commits] C11 <stdatomic.h>

[Richard Smith]

Ping.

On Mon, Sep 24, 2012 at 8:44 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> Ping.
>
>
> On Tue, Sep 18, 2012 at 6:47 PM, Richard Smith <richard at metafoo.co.uk>wrote:
>
>> On Mon, Sep 17, 2012 at 4:11 PM, Eli Friedman <eli.friedman at gmail.com>wrote:
>>
>>> On Sat, Sep 15, 2012 at 1:05 AM, Richard Smith <richard at metafoo.co.uk>
>>> wrote:
>>> >
>>> >
>>> > On Fri, Sep 14, 2012 at 8:17 PM, Eli Friedman <eli.friedman at gmail.com>
>>> > wrote:
>>> >>
>>> >> On Fri, Sep 14, 2012 at 7:48 PM, Richard Smith <richard at metafoo.co.uk
>>> >
>>> >> wrote:
>>> >> > Hi,
>>> >> >
>>> >> > The attached patch adds an implementation of <stdatomic.h> to the
>>> set of
>>> >> > headers provided by Clang. Since this header is so
>>> compiler-dependent,
>>> >> > it
>>> >> > seems that we are the most rational component to be providing this
>>> >> > header
>>> >> > (even though, for instance, some flavors of BSD already provide
>>> their
>>> >> > own).
>>> >> > Please review!
>>> >>
>>> >> +// Clang allows memory_order_consume ordering for __c11_atomic_store,
>>> >> +// even though C11 doesn't allow it for atomic_store.
>>> >>
>>> >> That looks like a bug...
>>> >
>>> >
>>> > Possibly it's a bug in the specification for atomic_flag_clear?
>>> > memory_order_consume doesn't seem to have any meaning for a store
>>> operation.
>>> >
>>> >>
>>> >> Please put the new warning in a separate commit.
>>> >
>>> >
>>> > r163964.
>>> >
>>> >> It looks like standard requires that we expose functions named
>>> >> atomic_thread_fence, atomic_signal_fence, atomic_flag_test_and_set,
>>> >> atomic_flag_test_and_set_explicit, and atomic_flag_clear; your version
>>> >> of stdatomic.h doesn't include declarations for these functions (which
>>> >> is required by C11 7.1.4p1).
>>> >
>>> >
>>> > Ugh. And C11 7.1.2/6 requires them to have external linkage. I don't
>>> want
>>> > these functions to require linking to a library. We could emit them
>>> weak and
>>> > inline, but then we'll get a weak copy in every TU which includes this
>>> > header, which seems fairly egregious. Is there currently any way to
>>> emit a
>>> > function as linkonce_odr from C? Do you have any suggestions as to how
>>> to
>>> > proceed?
>>>
>>> There isn't any way to get linkonce_odr from C at the moment; patches
>>> welcome.  I don't see any issues with that from the standpoint of the
>>> standard; I'm a little worried about ABI-compat issues, though.
>>> (Specifically, if the system provides the header, having our own
>>> linkonce_odr version could cause strange linker errors.)
>>>
>>> We could put it into compiler-rt, and say that if someone tries to use
>>> the function instead of the macro without linking in compiler-rt,
>>> that's an error.  Not particularly satisfying either, but somewhat
>>> simpler.
>>
>>
>> After some discussion with Chandler, we think the best approach is to say
>> that the definition of these functions belongs in libc, and to provide only
>> declarations of them. A patch for that approach is attached.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121002/a9676262/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stdatomic.diff
Type: application/octet-stream
Size: 17823 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121002/a9676262/attachment.obj>