In D87562#2277788, @vitalybuka wrote:

Can you please clang format it as well

In D87562#2269791, @vitalybuka wrote:

I prefer we use just "inline"

std::atomic_is_lock_free or an reimplementation of it (without pulling C++ runtime), testing a type and asserting that in runtime or build time that it is lockfree.

I've verified that this symbol has unlikely any clashes with 3rd party software now. https://grep.app/search?q=ATTR_INLINE&case=true&words=true

These "linux" files will be ported to BSD so we might pick better names now.

Please note that ncurses is not the only supported curses library. NetBSD uses its original BSD curses for LLVM projects.

In D76665#2237050, @lebedev.ri wrote:

In D76665#2161919, @krytarowski wrote:

In D76665#2140245, @kcc wrote:

Will adding attribute((no_sanitize("address"))) to your global solve the problem you are trying to solve?
(sorry for being too terse last time)

It does not work (last time I checked).

Does not work how?

Also GCC does the same thing of not instrumenting user defined sections.

Ping?

Ping?

@glider + @pcc please have a look!

In D76665#2140245, @kcc wrote:

Will adding attribute((no_sanitize("address"))) to your global solve the problem you are trying to solve?
(sorry for being too terse last time)

In D81105#2072158, @jfb wrote:

Please clarify what this is adding in the patch description.

It looks fine to me, but I will defer it to @dvyukov

OK, we will need to live with -Wno*.

Example error:

In D79846#2033705, @theraven wrote:

It should already be buildable out of the box. The missing prototypes warning is opt-in. I am not particularly in favour of changes motivated solely by an external build system that explicitly opts in to warnings that don't make sense for a particular compilation unit.

In D79846#2033589, @theraven wrote:

I'm guessing that this is explicitly enabling the missing prototypes warning. I'm not a huge fan of that for compilation units that don't have public headers, it makes the code more complex and doesn't catch any bugs. It's valuable only when you have a public header and want to ensure that it's in sync with the implementation.

https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html

I've separated two independent changes out of this revision into a separate review.
D79845 + D79846.

In D79713#2032372, @ldionne wrote:

In D79713#2032236, @krytarowski wrote:

will be "stuck" making sure that libatomic builds on GCC forever.

Generally... we [used to] build everything in compiler-rt with GCC except this single file.

Interesting! Where is the corresponding build system change in this patch?

will be "stuck" making sure that libatomic builds on GCC forever.

I rewrote this code again to support GCC. This time without removal of _Atomic().

In D79713#2031145, @theraven wrote:

it's quite easy to define a C++ template that switches from lock-free to having an inline lock

In D79713#2031145, @theraven wrote:

To give some background (please correct me if I'm wrong): This is initially motivated by having snmalloc working on NetBSD.

• drop ABI change in __atomic_compare_exchange_##n

In D79713#2029514, @jfb wrote:

Without looking at the details, this generally seems fine... but why is this desirable? The commit message should have that information. If there's not really a reason then I'd rather leave it alone and not change something that's fine.

In D79713#2029387, @theraven wrote:

I don't think that this should be including <stdatomic.h>. These routines are used to implement interfaces in <stdatomic.h> and it would be completely valid for a conforming implementation to use _Generic macros to directly call these functions from things in <stdatomic.h> that we then depend call, giving a circular dependency.

I don't particularly object to moving this to using the GCC builtins, since clang supports both the GCC ones and the __c11 ones, but the only two valid implementations of the routines in this file are to use compiler builtins or inline assembly.

Autogeneration of the code puts extra burden on us for tracking what is defined where and for repackaging LLDB with custom build rules (we need plain Makefile in the distribution). I presume the same problem is for gn users, for FreeBSD etc.

systems were not supported by hard coding 560

NetBSD fix landed here:

I will mirror it in NetBSD whatever will be decided here.

For fixing NetBSD, remember to go for #define sigaltstack __sigaltstack14 as the symbol is renamed.

(!defined(__MUSL__) || !__MUSL__) is pretty ugly. There is obviously a need for SANITIZER_MUSL, but then it's up to Linux maintainers whether to accept it.

LLVM Release Schedule: 10.0.0: Jan 15, 2020: branch, then rc1

Ping?

• rebase to HEAD