Re: PATCH libatomic

[christos%astron.com@localhost (Christos Zoulas)]

In article <9d775d79-026a-f52a-ae3c-39a00eea44b2%gmx.com@localhost>,
Kamil Rytarowski  <n54%gmx.com@localhost> wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 08.05.2020 21:33, maya%NetBSD.org@localhost 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