On Mon, Sep 17, 2012 at 4:11 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Sat, Sep 15, 2012 at 1:05 AM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
><br>
><br>
> On Fri, Sep 14, 2012 at 8:17 PM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On Fri, Sep 14, 2012 at 7:48 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>> wrote:<br>
>> > Hi,<br>
>> ><br>
>> > The attached patch adds an implementation of <stdatomic.h> to the set of<br>
>> > headers provided by Clang. Since this header is so compiler-dependent,<br>
>> > it<br>
>> > seems that we are the most rational component to be providing this<br>
>> > header<br>
>> > (even though, for instance, some flavors of BSD already provide their<br>
>> > own).<br>
>> > Please review!<br>
>><br>
>> +// Clang allows memory_order_consume ordering for __c11_atomic_store,<br>
>> +// even though C11 doesn't allow it for atomic_store.<br>
>><br>
>> That looks like a bug...<br>
><br>
><br>
> Possibly it's a bug in the specification for atomic_flag_clear?<br>
> memory_order_consume doesn't seem to have any meaning for a store operation.<br>
><br>
>><br>
>> Please put the new warning in a separate commit.<br>
><br>
><br>
> r163964.<br>
><br>
>> It looks like standard requires that we expose functions named<br>
>> atomic_thread_fence, atomic_signal_fence, atomic_flag_test_and_set,<br>
>> atomic_flag_test_and_set_explicit, and atomic_flag_clear; your version<br>
>> of stdatomic.h doesn't include declarations for these functions (which<br>
>> is required by C11 7.1.4p1).<br>
><br>
><br>
> Ugh. And C11 7.1.2/6 requires them to have external linkage. I don't want<br>
> these functions to require linking to a library. We could emit them weak and<br>
> inline, but then we'll get a weak copy in every TU which includes this<br>
> header, which seems fairly egregious. Is there currently any way to emit a<br>
> function as linkonce_odr from C? Do you have any suggestions as to how to<br>
> proceed?<br>
<br>
</div></div>There isn't any way to get linkonce_odr from C at the moment; patches<br>
welcome.  I don't see any issues with that from the standpoint of the<br>
standard; I'm a little worried about ABI-compat issues, though.<br>
(Specifically, if the system provides the header, having our own<br>
linkonce_odr version could cause strange linker errors.)<br>
<br>
We could put it into compiler-rt, and say that if someone tries to use<br>
the function instead of the macro without linking in compiler-rt,<br>
that's an error.  Not particularly satisfying either, but somewhat<br>
simpler.</blockquote><div><br></div><div>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.</div>
</div>