tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: PATCH libatomic

In article <>,
Kamil Rytarowski  <> wrote:
>On 08.05.2020 21:33, 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
> 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
>    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:

Looks like it was a bad idea :-)


Home | Main Index | Thread Index | Old Index