>> 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: >>>>>>> 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.
If the compiler provides stdatomic.h but libc implements the functions then all compilers need to have a binary compatible definition of memory_order and atomic_flag types. The patch implements atomic_flag on top of atomic_bool, but that means atomic_flag f = ATOMIC_FLAG_INIT is an atomic store. I think you need to use volatile _Bool instead (or actually volatile char because the value stored in it doesn't have to be 1) and use the __atomic_test_and_set and __atomic_clear built-ins. Also instead of including stdint.h and stddef.h, maybe you can use preprocessor macros like __INT8_TYPE__. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
