Ping. On Mon, Sep 24, 2012 at 8:44 PM, Richard Smith <[email protected]>wrote:
> Ping. > > > On Tue, Sep 18, 2012 at 6:47 PM, Richard Smith <[email protected]>wrote: > >> On Mon, Sep 17, 2012 at 4:11 PM, Eli Friedman <[email protected]>wrote: >> >>> On Sat, Sep 15, 2012 at 1:05 AM, Richard Smith <[email protected]> >>> wrote: >>> > >>> > >>> > On Fri, Sep 14, 2012 at 8:17 PM, Eli Friedman <[email protected]> >>> > wrote: >>> >> >>> >> On Fri, Sep 14, 2012 at 7:48 PM, Richard Smith <[email protected] >>> > >>> >> 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. >> > >
stdatomic.diff
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
