----- Original Message ----- > From: "David Chisnall" <[email protected]> > To: "Hal Finkel" <[email protected]> > Cc: "Richard Smith" <[email protected]>, "cfe commits" > <[email protected]>, "Eli Friedman" > <[email protected]>, "Tijl Coosemans" <[email protected]>, "Jeffrey > Yasskin" <[email protected]>, > "chandlerc" <[email protected]>, "John McCall" <[email protected]> > Sent: Sunday, September 21, 2014 5:44:50 AM > Subject: Re: [cfe-commits] C11 <stdatomic.h> > > We currently have a situation in FreeBSD where several of the > clang-provided headers are incompatible with the system headers, and > I'd prefer to avoid adding to this. Our stdatomic.h is carefully > designed to work with gcc 4.2.1, clang, and newer GCC, so we > definitely wouldn't want to replace it with something > clang-specific. Having clang provide a subset of the C standard > headers, independent of the C library, is quite unhelpful to us.
But gcc does this too, how do you deal with this generally? Regardless, we do need a way to deal with the fact that FreeBSD does have a Clang-compatible stdatomic.h (and other systems might too at some point). One potential solution is to structure the header to prefer a system implementation: #if __has_include_next(<stdatomic.h>) # include_next <stdatomic.h> #else ... (our fall-back implementation) #endif We might also need to deal with cases where the system does provide a stdatomic.h, but it is not Clang-compatible. To deal with this, we might have the targets with known-Clang-compatible implementations define something (like __CLANG_PREFER_SYSTEM_STDATOMIC_H), and then key off that instead. What do you think? Thanks again, Hal > > David > > On 21 Sep 2014, at 00:09, Hal Finkel <[email protected]> wrote: > > > Richard, > > > > I'd like to re-open this issue; our last thread on this seemed to > > fizzle out with a discussion on how the ABI should be defined, > > Clang/LLVM bugs and probable C11 (or perhaps C++11) defects. This, > > however, still leaves our users in the somewhat-unfortunate > > situation of not having a stdatomic.h header when using Clang on > > Linux (and several other platforms) -- and to make matters worse, > > we also don't define __STDC_NO_ATOMICS__. I've received requests > > from several of my users to resolve this issue, and I think that > > we should move-forward with adding this header. As I'm sure you > > know, GCC 4.9 now ships a stdatomic.h, as does FreeBSD. Both seem > > to use _Bool as the underlying type for atomic_flag (at least when > > __GCC_ATOMIC_TEST_AND_SET_TRUEVAL == 1). > > > > Regarding atomic_flag_test_and_set and friends, and whether these > > will be defined by libc, regardless of whether we provide proper > > definitions, we should follow GCC 4.9 and FreeBSD and define these > > functions as macros (this is allowed by 7.1.4). This provides > > users with a fully-functional header file regardless of whether > > the system libc provides the required external function > > implementations (I don't know of any that do). > > > > Thanks again, > > Hal > > > > ----- Original Message ----- > >> From: "Richard Smith" <[email protected]> > >> To: "Eli Friedman" <[email protected]> > >> Cc: "cfe commits" <[email protected]> > >> Sent: Tuesday, September 18, 2012 8:47:37 PM > >> Subject: Re: [cfe-commits] C11 <stdatomic.h> > >> > >> > >> 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. > >> _______________________________________________ > >> cfe-commits mailing list > >> [email protected] > >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > >> > > > > -- > > Hal Finkel > > Assistant Computational Scientist > > Leadership Computing Facility > > Argonne National Laboratory > > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
