Re: atomic in i386 Current after CLANG 6 upgrade
On Mon, 15 Jan 2018 18:37:47 +0100 Dimitry Andric wrote: > On 15 Jan 2018, at 11:43, Luca Pizzamiglio wrote: >> 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. > > [1] https://bugs.llvm.org/show_bug.cgi?id=34347 It looks to me clang is doing fewer libcalls now and more inlining, which is why the configure tests succeed now. That clang generates cmpxchg8b on i486 has always been the case. The fix for 34347 exposes this more now. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: atomic in i386 Current after CLANG 6 upgrade
On Mon, 15 Jan 2018 17:08:58 + David Chisnall wrote: > On 15 Jan 2018, at 17:00, Jan Beich wrote: >> 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. 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? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: atomic in i386 Current after CLANG 6 upgrade
On 15 Jan 2018, at 11:43, Luca Pizzamiglio wrote: > > 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 signature.asc Description: Message signed with OpenPGP
Re: atomic in i386 Current after CLANG 6 upgrade
On Mon, Jan 15, 2018 at 10:08 AM, David Chisnall wrote: > On 15 Jan 2018, at 17:00, Jan Beich wrote: > > > > 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. > So far clang 6 is just in -current. Let's at least get them there first before we talk about ENs :) Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: atomic in i386 Current after CLANG 6 upgrade
On 15 Jan 2018, at 17:00, Jan Beich wrote: > > 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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: atomic in i386 Current after CLANG 6 upgrade
Tijl Coosemans writes: > On Mon, 15 Jan 2018 11:43:44 +0100 Luca Pizzamiglio > wrote: > >> 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 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) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: atomic in i386 Current after CLANG 6 upgrade
On Mon, 15 Jan 2018 11:43:44 +0100 Luca Pizzamiglio wrote: > 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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
atomic in i386 Current after CLANG 6 upgrade
Hy all, 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 ? Thanks in advance! Best regards, pizzamg [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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"