In article <9d775d79-026a-f52a-ae3c-39a00eea4...@gmx.com>, Kamil Rytarowski <n...@gmx.com> wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >On 08.05.2020 21:33, m...@netbsd.org wrote: >> On Fri, May 08, 2020 at 04:09:02PM +0200, Kamil Rytarowski wrote: >>> I object to opinions that libatomic is generally broken, if that would >>> be the cause, it wouldn't be available and used on relatively all >>> relevant generic purpose Operating Systems. Personally, I already >>> received last year a feedback from one 3rd party project from Microsoft >>> that they prefer to drop NetBSD support (out of Windows, Linux, MacOS, >>> BSDs) rather than allow non-libatomic usage. >> >> You need to stop being ambiguous about the rationale, it's not helping >> your arguments sound strong. Name the project and link to the >> discussion. >> > > >NetBSD support #77 >https://github.com/microsoft/snmalloc/pull/77#issuecomment-517375185 > > davidchisnall commented on 1 Aug 2019 > >If the NetBSD developers disagree with the libatomic idea, what is their >alternative? Or do they just decide not to support C11 / C++11? I'll >happily review a patch to properly support NetBSD (which means linking >whatever the NetBSD equivalent of libatomic is), but otherwise it's >probably better to remove the NetBSD PAL rather than leave something >that only works in non-default configurations. > > davidchisnall commented on 1 Aug 2019 > >We only need 128-bit atomics, but it sounds as if the compiler that >NetBSD ships by default does not emit 128-bit atomics even with the >-mcx16 flag. There are three reasonable approaches here: > > Ship libatomics. > Ship another library that provides these symbols (e.g. put them in >libc). > Ship a compiler that implements _Atomic in some other way and does >not depend on the __atomic_compare_exchange_{16,n} symbols. > >Shipping a compiler that emits calls to support library functions and >then not shipping the support library is the worst possible solution. >The required CMake changes on our side would be quite complex unless we >just say reject trying to compile with gcc on NetBSD entirely. > > davidchisnall commented on 2 Aug 2019 > >We only add libatomic when compiling with gcc, so I think the current >logic is correct. If NetBSD ever ships a version of GCC that actually >works, then we can revisit this, otherwise NetBSD users will get an >error when they try to link with GCC but have everything work when they >compile with clang. >
Gcc broke it on purpose: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 Looks like it was a bad idea :-) christos
