atomic in i386 Current after CLANG 6 upgrade

[Jan Beich]

I've already received a couple of messages from pkg-fallout about build
failure on head-i386-default [1] [2] both pointing to the same errors,
about missing intrinsic symbols related to __atomic_*
The clang documentation about C11 atomic builtins [3] stats that __atomic_*
are GCC extension and Clang provides them.
It seems to me that this specific GCC-compatible builtin are enabled on
amd64, but not on i386.
Is there a way to enable GCC compatible __atomic_ builtin also on i386?
Or should I provide patches to adopt _c11_atomic_* instead of __atomic_*
for every ports that need it ?
[1]
http://beefy11.nyi.freebsd.org/data/head-i386-default/p458948_s327953/logs/librdkafka-0.11.3.log
[2]
http://beefy11.nyi.freebsd.org/data/head-i386-default/p458948_s327953/logs/stress-ng-0.09.09.log
[3] https://clang.llvm.org/docs/LanguageExtensions.html#langext-c11-atomic

8 byte atomics requires at least i586. So either find a way to disable
the use of these atomics in these ports or add something like this to
the port Makefile.
.if ${ARCH} == i386 && ! ${MACHINE_CPU:Mi586}
CFLAGS+= -march=i586
.endif

It wouldn't help (see below). Clang 6 accidentally made __atomic* work
enough to satisfy configure check but not for the port to build. I guess,
it also confuses configure in net/librdkafka and net-mgmt/netdata.

$ cat a.c
#include <stdint.h>

typedef struct {
uint64_t val64;
} atomic_t;

int main()
{
uint64_t foo;
atomic_t bar;
#ifdef ATOMIC_STRUCT
__atomic_fetch_add(&bar.val64, 1, __ATOMIC_RELAXED);
#else
__atomic_fetch_add(&foo, 1, __ATOMIC_RELAXED);
#endif
return 0;
}

$ cc -m32 -march=i586 a.c
$ clang50 -m32 -march=i586 a.c
/tmp/a-560ad1.o: In function `main':
a.c:(.text+0x46): undefined reference to `__atomic_fetch_add_8'
clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)

$ cc -m32 -DATOMIC_STRUCT -march=i586 a.c
/usr/bin/ld: error: undefined symbol: __atomic_fetch_add_8

referenced by a.c
/tmp/a-ad8c36.o:(main)

cc: error: linker command failed with exit code 1 (use -v to see invocation)
$ clang50 -m32 -DATOMIC_STRUCT -march=i586 a.c
/tmp/a-0fbfd0.o: In function `main':
a.c:(.text+0x46): undefined reference to `__atomic_fetch_add_8'
clang-5.0: error: linker command failed with exit code 1 (use -v to see invocation)

[David Chisnall]

Post by Jan Beich
It wouldn't help (see below). Clang 6 accidentally made __atomic* work
enough to satisfy configure check but not for the port to build. I guess,
it also confuses configure in net/librdkafka and net-mgmt/netdata.

Can we (by which I probably mean emaste@) push out an EN that adds the atomic.c from compiler-rt to our libgcc_s? That should provide all of these helper functions. Clang assumes that they exist because both compiler-rt and vaguely recent libgcc_s provide them. Recent GCC will also assume that they exist and so the correct fix is probably for us to make them to exist.

If this is difficult, then we can perhaps provide a port that compiles atomic.c into libatomic_fudge.so or similar and provides a libgcc_s.so that’s a linker script that forces linking to libatomic_fudge.so and libgcc_s.so.

David

[Warner Losh]

Post by David Chisnall

Post by Jan Beich
It wouldn't help (see below). Clang 6 accidentally made __atomic* work
enough to satisfy configure check but not for the port to build. I guess,
it also confuses configure in net/librdkafka and net-mgmt/netdata.

atomic.c from compiler-rt to our libgcc_s? That should provide all of
these helper functions. Clang assumes that they exist because both
compiler-rt and vaguely recent libgcc_s provide them. Recent GCC will also
assume that they exist and so the correct fix is probably for us to make
them to exist.
If this is difficult, then we can perhaps provide a port that compiles
atomic.c into libatomic_fudge.so or similar and provides a libgcc_s.so
that’s a linker script that forces linking to libatomic_fudge.so and
libgcc_s.so.

So far clang 6 is just in -current. Let's at least get them there first
before we talk about ENs :)

Warner

[Tijl Coosemans]

Post by David Chisnall

Post by Jan Beich
It wouldn't help (see below). Clang 6 accidentally made __atomic* work
enough to satisfy configure check but not for the port to build. I guess,
it also confuses configure in net/librdkafka and net-mgmt/netdata.

atomic.c from compiler-rt to our libgcc_s? That should provide all of
these helper functions. Clang assumes that they exist because both
compiler-rt and vaguely recent libgcc_s provide them. Recent GCC will
also assume that they exist and so the correct fix is probably for us
to make them to exist.
If this is difficult, then we can perhaps provide a port that compiles
atomic.c into libatomic_fudge.so or similar and provides a libgcc_s.so
that’s a linker script that forces linking to libatomic_fudge.so and
libgcc_s.so.

I can understand emitting function calls on i486 but according to Jan,
clang is emitting function calls on i586 as well. It used to inline
this which is why we never needed these functions in libgcc. Is it
normal that clang emits function calls now?

[Dimitry Andric]

I've already received a couple of messages from pkg-fallout about build
failure on head-i386-default [1] [2] both pointing to the same errors,
about missing intrinsic symbols related to __atomic_*
The clang documentation about C11 atomic builtins [3] stats that __atomic_*
are GCC extension and Clang provides them.
It seems to me that this specific GCC-compatible builtin are enabled on
amd64, but not on i386.
Is there a way to enable GCC compatible __atomic_ builtin also on i386?
Or should I provide patches to adopt _c11_atomic_* instead of __atomic_*
for every ports that need it ?

There is some strangeness going on with an upstream bug fix [1], which
has the unintended side effect of sometimes emitting libcalls to
__atomic functions that we do not have on i386. I've commented on the
upstream bug report, but I do not know an easy workaround at this
point.

-Dimitry

[1] https://bugs.llvm.org/show_bug.cgi?id=34347