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? Thanks! Richard
stdatomic.diff
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
