[libcxx-dev] proposal: decoupling Freestanding atomic<T> from libatomic.a

[Ben Craig via libcxx-dev]

I think the most robust solution is for your compiler to implement C11 _Atomic, and for that type to be sufficiently large to hold your value and your spin lock.  I think that most of the libcxx implementation will "just work" at that point, although there are possibly some hidden bugs where something mistakenly assumes that sizeof(T) = = sizeof(_Atomic(T)).


Making the compiler generate _Atomic correctly also gives you a lot of C compatibility.


If C11 compatibility isn't a big concern, and / or getting that feature into the compilers that you need isn't an option, then your approach sounds fine to me.  I don't make the decisions around here though :)


For the binary compatibility concerns... I don't have great answers.  On the one hand, I want to believe that the choice of freestanding or hosted is a platform decision, and that you shouldn't ever mix freestanding object files with hosted object files.  On the other hand, an awful lot of people that aren't doing embedded, drivers, or GPU programming seem interested in freestanding, and I'm afraid that they may very well want to build one chunk of code with a freestanding flag as a style checker / optimizer, and another part of their code with hosted.  I'm not sure if it make sense to try and support that second group.


Another binary compatibility note... my search skills are failing me, but I recall seeing some blog post or documentation that basically states that, when in doubt, you should generate a library call.  You can migrate from a library call to inline code over time, but you can't migrate the other direction without breaking compatibility.  I don't think that affects the specific design questions you had though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190101/c0ed9bc4/attachment.html>