Re: atomic in i386 Current after CLANG 6 upgrade

[Tijl Coosemans]

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-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: atomic in i386 Current after CLANG 6 upgrade

[Tijl Coosemans]

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-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: atomic in i386 Current after CLANG 6 upgrade

[Dimitry Andric]

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

[Jan Beich]

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(, 1, __ATOMIC_RELAXED);
#else
  __atomic_fetch_add(, 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-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: atomic in i386 Current after CLANG 6 upgrade

[Tijl Coosemans]

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-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"