Re: Undefined reference to __atomic_store_8
On Thu, 13 Aug 2020 17:38:41 +0400 Gleb Popov wrote: > Still, I'm curious where I can get __atomic_load_n in an i386 case, if I > don't want to pull in gcc? There's an implementation in libcompiler_rt but we don't build it. It doesn't look correct in this case because it seems to use FILDLL. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Wed, Aug 12, 2020 at 3:42 PM Tijl Coosemans wrote:
> On Wed, 12 Aug 2020 09:44:25 +0400 Gleb Popov wrote:
> > On Wed, Aug 12, 2020 at 9:21 AM Gleb Popov wrote:
> >> Indeed, this looks like a culprit! When compiling using first command
> line
> >> (the long one) I get following warnings:
> >>
> >>
> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c:369:10:
> >> warning: misaligned atomic operation may incur significant performance
> >> penalty [-Watomic-alignment]
> >> return __atomic_load_n((StgWord64 *) x, __ATOMIC_SEQ_CST);
> >> ^
> >>
> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c:417:3:
> >> warning: misaligned atomic operation may incur significant performance
> >> penalty [-Watomic-alignment]
> >> __atomic_store_n((StgWord64 *) x, (StgWord64) val, __ATOMIC_SEQ_CST);
> >> ^
> >> 2 warnings generated.
> >>
> >> I guess this basically means "I'm emitting a call there". So, what's the
> >> correct fix in this case?
> >
> > I just noticed that Clang emits these warnings (and the call instruction)
> > only for functions handling StgWord64 type. For the same code with
> > StgWord32, like
> >
> > StgWord
> > hs_atomicread32(StgWord x)
> > {
> > #if HAVE_C11_ATOMICS
> > return __atomic_load_n((StgWord32 *) x, __ATOMIC_SEQ_CST);
> > #else
> > return __sync_add_and_fetch((StgWord32 *) x, 0);
> > #endif
> > }
> >
> > no warning is emitted as well as no call.
> >
> > How does clang infer alignment in these cases? What's so special about
> > StgWord64?
>
> StgWord64 is uint64_t which is unsigned long long which is 4 byte
> aligned on i386. Clang wants 8 byte alignment to use the fildll
> instruction.
>
> You could change the definition of the StgWord64 type to look like:
>
> typedef uint64_t StgWord64 __attribute__((aligned(8)));
>
> But this only works if all calls to hs_atomicread64 pass a StgWord64
> as argument and not some other 64 bit value.
>
>
> Another solution I already mentioned in a previous message: replace
> HAVE_C11_ATOMICS with 0 in hs_atomicread64 so it uses
> __sync_add_and_fetch instead of __atomic_load_n. That uses the
> cmpxchg8b instruction which doesn't care about alignment. It's much
> slower but I guess 64 bit atomic loads are rare enough that this
> doesn't matter much.
>
Yep, your suggested workaround worked, many thanks.
Still, I'm curious where I can get __atomic_load_n in an i386 case, if I
don't want to pull in gcc?
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Wed, 12 Aug 2020 17:35:17 +0300 Konstantin Belousov wrote: > On Wed, Aug 12, 2020 at 01:41:58PM +0200, Tijl Coosemans wrote: >> StgWord64 is uint64_t which is unsigned long long which is 4 byte >> aligned on i386. Clang wants 8 byte alignment to use the fildll >> instruction. > This all is very strange. > > How could code use fildll to load 8 bytes as bit-value ? FILDLL converts > single and double precision fp into long-double fp, so it would change > the bit-value. FILDLL loads long long and converts it to long double which has 64 bit mantissa so the value is unchanged. > Also, both ISA and x86 psABI only require 4-byte alignment for the > double precision fp variables. > > If the variable memory spans over two cache lines, then SDM states that > the access can be not atomic, but I believe it cannot happen for any > existing CPU. It might be slow. For some future CPUs, Intel provides > control which would cause such accesses to trap. Well, it seems clang follows the SDM and assumes 8 byte alignment is needed because then the variable never crosses a cache line boundary. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Wed, Aug 12, 2020 at 01:41:58PM +0200, Tijl Coosemans wrote:
> On Wed, 12 Aug 2020 09:44:25 +0400 Gleb Popov wrote:
> > On Wed, Aug 12, 2020 at 9:21 AM Gleb Popov wrote:
> >> Indeed, this looks like a culprit! When compiling using first command line
> >> (the long one) I get following warnings:
> >>
> >> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c:369:10:
> >> warning: misaligned atomic operation may incur significant performance
> >> penalty [-Watomic-alignment]
> >> return __atomic_load_n((StgWord64 *) x, __ATOMIC_SEQ_CST);
> >> ^
> >> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c:417:3:
> >> warning: misaligned atomic operation may incur significant performance
> >> penalty [-Watomic-alignment]
> >> __atomic_store_n((StgWord64 *) x, (StgWord64) val, __ATOMIC_SEQ_CST);
> >> ^
> >> 2 warnings generated.
> >>
> >> I guess this basically means "I'm emitting a call there". So, what's the
> >> correct fix in this case?
> >
> > I just noticed that Clang emits these warnings (and the call instruction)
> > only for functions handling StgWord64 type. For the same code with
> > StgWord32, like
> >
> > StgWord
> > hs_atomicread32(StgWord x)
> > {
> > #if HAVE_C11_ATOMICS
> > return __atomic_load_n((StgWord32 *) x, __ATOMIC_SEQ_CST);
> > #else
> > return __sync_add_and_fetch((StgWord32 *) x, 0);
> > #endif
> > }
> >
> > no warning is emitted as well as no call.
> >
> > How does clang infer alignment in these cases? What's so special about
> > StgWord64?
>
> StgWord64 is uint64_t which is unsigned long long which is 4 byte
> aligned on i386. Clang wants 8 byte alignment to use the fildll
> instruction.
This all is very strange.
How could code use fildll to load 8 bytes as bit-value ? FILDLL converts
single and double precision fp into long-double fp, so it would change
the bit-value.
Also, both ISA and x86 psABI only require 4-byte alignment for the
double precision fp variables.
If the variable memory spans over two cache lines, then SDM states that
the access can be not atomic, but I believe it cannot happen for any
existing CPU. It might be slow. For some future CPUs, Intel provides
control which would cause such accesses to trap.
>
> You could change the definition of the StgWord64 type to look like:
>
> typedef uint64_t StgWord64 __attribute__((aligned(8)));
>
> But this only works if all calls to hs_atomicread64 pass a StgWord64
> as argument and not some other 64 bit value.
>
>
> Another solution I already mentioned in a previous message: replace
> HAVE_C11_ATOMICS with 0 in hs_atomicread64 so it uses
> __sync_add_and_fetch instead of __atomic_load_n. That uses the
> cmpxchg8b instruction which doesn't care about alignment. It's much
> slower but I guess 64 bit atomic loads are rare enough that this
> doesn't matter much.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Wed, 12 Aug 2020 09:44:25 +0400 Gleb Popov wrote:
> On Wed, Aug 12, 2020 at 9:21 AM Gleb Popov wrote:
>> Indeed, this looks like a culprit! When compiling using first command line
>> (the long one) I get following warnings:
>>
>> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c:369:10:
>> warning: misaligned atomic operation may incur significant performance
>> penalty [-Watomic-alignment]
>> return __atomic_load_n((StgWord64 *) x, __ATOMIC_SEQ_CST);
>> ^
>> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c:417:3:
>> warning: misaligned atomic operation may incur significant performance
>> penalty [-Watomic-alignment]
>> __atomic_store_n((StgWord64 *) x, (StgWord64) val, __ATOMIC_SEQ_CST);
>> ^
>> 2 warnings generated.
>>
>> I guess this basically means "I'm emitting a call there". So, what's the
>> correct fix in this case?
>
> I just noticed that Clang emits these warnings (and the call instruction)
> only for functions handling StgWord64 type. For the same code with
> StgWord32, like
>
> StgWord
> hs_atomicread32(StgWord x)
> {
> #if HAVE_C11_ATOMICS
> return __atomic_load_n((StgWord32 *) x, __ATOMIC_SEQ_CST);
> #else
> return __sync_add_and_fetch((StgWord32 *) x, 0);
> #endif
> }
>
> no warning is emitted as well as no call.
>
> How does clang infer alignment in these cases? What's so special about
> StgWord64?
StgWord64 is uint64_t which is unsigned long long which is 4 byte
aligned on i386. Clang wants 8 byte alignment to use the fildll
instruction.
You could change the definition of the StgWord64 type to look like:
typedef uint64_t StgWord64 __attribute__((aligned(8)));
But this only works if all calls to hs_atomicread64 pass a StgWord64
as argument and not some other 64 bit value.
Another solution I already mentioned in a previous message: replace
HAVE_C11_ATOMICS with 0 in hs_atomicread64 so it uses
__sync_add_and_fetch instead of __atomic_load_n. That uses the
cmpxchg8b instruction which doesn't care about alignment. It's much
slower but I guess 64 bit atomic loads are rare enough that this
doesn't matter much.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Wed, Aug 12, 2020 at 9:21 AM Gleb Popov wrote:
> Indeed, this looks like a culprit! When compiling using first command line
> (the long one) I get following warnings:
>
> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c:369:10:
> warning: misaligned atomic operation may incur significant performance
> penalty [-Watomic-alignment]
> return __atomic_load_n((StgWord64 *) x, __ATOMIC_SEQ_CST);
> ^
> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c:417:3:
> warning: misaligned atomic operation may incur significant performance
> penalty [-Watomic-alignment]
> __atomic_store_n((StgWord64 *) x, (StgWord64) val, __ATOMIC_SEQ_CST);
> ^
> 2 warnings generated.
>
> I guess this basically means "I'm emitting a call there". So, what's the
> correct fix in this case?
>
I just noticed that Clang emits these warnings (and the call instruction)
only for functions handling StgWord64 type. For the same code with
StgWord32, like
StgWord
hs_atomicread32(StgWord x)
{
#if HAVE_C11_ATOMICS
return __atomic_load_n((StgWord32 *) x, __ATOMIC_SEQ_CST);
#else
return __sync_add_and_fetch((StgWord32 *) x, 0);
#endif
}
no warning is emitted as well as no call.
How does clang infer alignment in these cases? What's so special about
StgWord64?
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Wed, Aug 12, 2020 at 1:52 AM Tijl Coosemans wrote: > On Tue, 11 Aug 2020 15:56:35 +0400 Gleb Popov wrote: > > On Sun, Aug 9, 2020 at 7:43 PM Konstantin Belousov > > wrote: > > > > > I do not believe there were any change in the toolchain between p2 and > p7, > > > this is more likely indicates some fluctuation in the build. The only > > > change that could be even remotely declared as possibly related is > > > EN-20:10.build r360473. > > > > > > > Right, I was using a wrong set of port's OPTIONS that hide the problem. > > > > Indeed you need to look at the .o files that reference _8 symbol. I > would > > > closely look at the compilation command used for them, for start. > > > > > > > After digging it a bit I found that the following command > > > > cc -x c > > > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c > > -o /tmp/ghc_1.s -fno-PIC -Wimplicit -S \ > > -include > > > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes/dist-install/build/ghcversion.h > > -I/usr/local/include \ > > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/base/include \ > > > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/base/dist-install/build/include > > \ > > > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/base/dist-install/build/dist-install/build/include > > \ > > > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/integer-gmp/include > > \ > > > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/integer-gmp/dist-install/build/include > > \ > > > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/integer-gmp/dist-install/build/dist-install/build/include > > \ > > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/rts/dist/build > > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes \ > > > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes/dist-derivedconstants/header > > \ > > > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes/dist-install/build \ > > -march=i686 -U__i686 > > > > produce an assembly file with > > > > calll __atomic_load_8 > > > > instruction. > > > > The value of -march flag seems to be ignored. > > > > Interestingly, previous version of GHC calls C compiler in the following > > way: > > > > cc -U__i686 '-march=i686' -fno-stack-protector -DTABLES_NEXT_TO_CODE > > '-march=i686' -x c > > > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c > > -o /tmp/ghc_1.s -Wimplicit -S \ > > -include > > > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.5-boot/lib/ghc-8.6.5/include/ghcversion.h > > \ > > -I/usr/local/include \ > > > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.5-boot/lib/ghc-8.6.5/base-4.12.0.0/include > > \ > > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.5-boot/lib/ghc-8.6.5/include > > > > And this command produces an assembly without calls to __atomic_load_8 > > > > Any ideas what makes it appear? > > Looking at atomic.c one possibility is that in the first command > HAVE_C11_ATOMICS is defined and not in the second. > > Apparently gcc always uses fild/fistp for __atomic_load_8 while clang > only uses it if the address is 8 byte aligned and generates a function > call otherwise. > Indeed, this looks like a culprit! When compiling using first command line (the long one) I get following warnings: /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c:369:10: warning: misaligned atomic operation may incur significant performance penalty [-Watomic-alignment] return __atomic_load_n((StgWord64 *) x, __ATOMIC_SEQ_CST); ^ /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c:417:3: warning: misaligned atomic operation may incur significant performance penalty [-Watomic-alignment] __atomic_store_n((StgWord64 *) x, (StgWord64) val, __ATOMIC_SEQ_CST); ^ 2 warnings generated. I guess this basically means "I'm emitting a call there". So, what's the correct fix in this case? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Tue, 11 Aug 2020 15:56:35 +0400 Gleb Popov wrote: > On Sun, Aug 9, 2020 at 7:43 PM Konstantin Belousov > wrote: > > > I do not believe there were any change in the toolchain between p2 and p7, > > this is more likely indicates some fluctuation in the build. The only > > change that could be even remotely declared as possibly related is > > EN-20:10.build r360473. > > > > Right, I was using a wrong set of port's OPTIONS that hide the problem. > > Indeed you need to look at the .o files that reference _8 symbol. I would > > closely look at the compilation command used for them, for start. > > > > After digging it a bit I found that the following command > > cc -x c > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c > -o /tmp/ghc_1.s -fno-PIC -Wimplicit -S \ > -include > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes/dist-install/build/ghcversion.h > -I/usr/local/include \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/base/include \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/base/dist-install/build/include > \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/base/dist-install/build/dist-install/build/include > \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/integer-gmp/include > \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/integer-gmp/dist-install/build/include > \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/integer-gmp/dist-install/build/dist-install/build/include > \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/rts/dist/build > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes/dist-derivedconstants/header > \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes/dist-install/build \ > -march=i686 -U__i686 > > produce an assembly file with > > calll __atomic_load_8 > > instruction. > > The value of -march flag seems to be ignored. > > Interestingly, previous version of GHC calls C compiler in the following > way: > > cc -U__i686 '-march=i686' -fno-stack-protector -DTABLES_NEXT_TO_CODE > '-march=i686' -x c > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c > -o /tmp/ghc_1.s -Wimplicit -S \ > -include > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.5-boot/lib/ghc-8.6.5/include/ghcversion.h > \ > -I/usr/local/include \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.5-boot/lib/ghc-8.6.5/base-4.12.0.0/include > \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.5-boot/lib/ghc-8.6.5/include > > And this command produces an assembly without calls to __atomic_load_8 > > Any ideas what makes it appear? Looking at atomic.c one possibility is that in the first command HAVE_C11_ATOMICS is defined and not in the second. Apparently gcc always uses fild/fistp for __atomic_load_8 while clang only uses it if the address is 8 byte aligned and generates a function call otherwise. I think you can patch atomic.c so hs_atomicread64 and hs_atomicwrite64 always use the non-C11 version. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Tue, Aug 11, 2020 at 03:56:35PM +0400, Gleb Popov wrote: > On Sun, Aug 9, 2020 at 7:43 PM Konstantin Belousov > wrote: > > > I do not believe there were any change in the toolchain between p2 and p7, > > this is more likely indicates some fluctuation in the build. The only > > change that could be even remotely declared as possibly related is > > EN-20:10.build r360473. > > > > Right, I was using a wrong set of port's OPTIONS that hide the problem. > > Indeed you need to look at the .o files that reference _8 symbol. I would > > closely look at the compilation command used for them, for start. > > > > After digging it a bit I found that the following command > > cc -x c > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c > -o /tmp/ghc_1.s -fno-PIC -Wimplicit -S \ > -include > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes/dist-install/build/ghcversion.h > -I/usr/local/include \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/base/include \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/base/dist-install/build/include > \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/base/dist-install/build/dist-install/build/include > \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/integer-gmp/include > \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/integer-gmp/dist-install/build/include > \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/integer-gmp/dist-install/build/dist-install/build/include > \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/rts/dist/build > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes/dist-derivedconstants/header > \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes/dist-install/build \ > -march=i686 -U__i686 > > produce an assembly file with > > calll __atomic_load_8 > > instruction. > > The value of -march flag seems to be ignored. > > Interestingly, previous version of GHC calls C compiler in the following > way: > > cc -U__i686 '-march=i686' -fno-stack-protector -DTABLES_NEXT_TO_CODE > '-march=i686' -x c > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c > -o /tmp/ghc_1.s -Wimplicit -S \ > -include > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.5-boot/lib/ghc-8.6.5/include/ghcversion.h > \ > -I/usr/local/include \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.5-boot/lib/ghc-8.6.5/base-4.12.0.0/include > \ > -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.5-boot/lib/ghc-8.6.5/include > > And this command produces an assembly without calls to __atomic_load_8 > > Any ideas what makes it appear? But was the compiler version identical in both cases ? Also, it might be that -O/-O2 could make a difference between inlining cmpxchg8b vs. calling libatomic, even with -march=i686. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Sun, Aug 9, 2020 at 4:37 PM Tijl Coosemans wrote: > On Sun, 9 Aug 2020 15:36:51 +0400 Gleb Popov wrote: > > On Sat, Aug 8, 2020 at 5:30 PM Konstantin Belousov > > wrote: > >> For code generated by gcc or clang, yes. > >> If the reference to the symbol was generated by ghc, then I do not know. > > > > This doesn't seem to work. > > > > The code referencing __atomic_load_n() is C and GHC buildsystem already > > passes -march=i686. Still, the problem persists. > > Interestingly, 12.1-RELEASE-p2 doesn't have this problem, but > > 12.1-RELEASE-p7 does. > > > > What library provides these symbols when clang is used? And I'm a bit > > obscured how -march flag can affect these symbols' visibility at all? > > There is no such library. i586 supports 64 bit atomic operations so > the compiler should emit instructions for that instead of a function > call. Check that *.o files that match "__atomic_load" are in fact built > with -march. > > 12.1-RELEASE-p7 probably has a newer clang that fixed an issue where the > compiler would always emit instructions, even for i386 and i486. > Ok, thanks for explanations. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Sun, Aug 9, 2020 at 7:43 PM Konstantin Belousov wrote: > I do not believe there were any change in the toolchain between p2 and p7, > this is more likely indicates some fluctuation in the build. The only > change that could be even remotely declared as possibly related is > EN-20:10.build r360473. > Right, I was using a wrong set of port's OPTIONS that hide the problem. Indeed you need to look at the .o files that reference _8 symbol. I would > closely look at the compilation command used for them, for start. > After digging it a bit I found that the following command cc -x c /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c -o /tmp/ghc_1.s -fno-PIC -Wimplicit -S \ -include /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes/dist-install/build/ghcversion.h -I/usr/local/include \ -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/base/include \ -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/base/dist-install/build/include \ -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/base/dist-install/build/dist-install/build/include \ -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/integer-gmp/include \ -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/integer-gmp/dist-install/build/include \ -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/integer-gmp/dist-install/build/dist-install/build/include \ -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/rts/dist/build -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes \ -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes/dist-derivedconstants/header \ -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes/dist-install/build \ -march=i686 -U__i686 produce an assembly file with calll __atomic_load_8 instruction. The value of -march flag seems to be ignored. Interestingly, previous version of GHC calls C compiler in the following way: cc -U__i686 '-march=i686' -fno-stack-protector -DTABLES_NEXT_TO_CODE '-march=i686' -x c /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c -o /tmp/ghc_1.s -Wimplicit -S \ -include /wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.5-boot/lib/ghc-8.6.5/include/ghcversion.h \ -I/usr/local/include \ -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.5-boot/lib/ghc-8.6.5/base-4.12.0.0/include \ -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.6.5-boot/lib/ghc-8.6.5/include And this command produces an assembly without calls to __atomic_load_8 Any ideas what makes it appear? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Sun, 9 Aug 2020 15:36:51 +0400 Gleb Popov wrote: > On Sat, Aug 8, 2020 at 5:30 PM Konstantin Belousov > wrote: >> For code generated by gcc or clang, yes. >> If the reference to the symbol was generated by ghc, then I do not know. > > This doesn't seem to work. > > The code referencing __atomic_load_n() is C and GHC buildsystem already > passes -march=i686. Still, the problem persists. > Interestingly, 12.1-RELEASE-p2 doesn't have this problem, but > 12.1-RELEASE-p7 does. > > What library provides these symbols when clang is used? And I'm a bit > obscured how -march flag can affect these symbols' visibility at all? There is no such library. i586 supports 64 bit atomic operations so the compiler should emit instructions for that instead of a function call. Check that *.o files that match "__atomic_load" are in fact built with -march. 12.1-RELEASE-p7 probably has a newer clang that fixed an issue where the compiler would always emit instructions, even for i386 and i486. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Sat, Aug 8, 2020 at 5:30 PM Konstantin Belousov wrote: > For code generated by gcc or clang, yes. > If the reference to the symbol was generated by ghc, then I do not know. > This doesn't seem to work. The code referencing __atomic_load_n() is C and GHC buildsystem already passes -march=i686. Still, the problem persists. Interestingly, 12.1-RELEASE-p2 doesn't have this problem, but 12.1-RELEASE-p7 does. What library provides these symbols when clang is used? And I'm a bit obscured how -march flag can affect these symbols' visibility at all? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Sat, 8 Aug 2020 12:37:42 +0400 Gleb Popov wrote:
> On Sat, Aug 8, 2020 at 1:29 AM Konstantin Belousov
> wrote:
>> On Fri, Aug 07, 2020 at 08:42:12PM +0400, Gleb Popov wrote:
>>> Hello toolchain@
>>>
>>> I'm testing a new release of GHC (Haskell compiler) and it fails to link
>>> to i386 architectures with
>>>
>>> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.6.1-ghc8.10.1.so:
>>> undefined reference to `__atomic_store_8'
>>>
>>> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.6.1-ghc8.10.1.so:
>>> undefined reference to `__atomic_load_8'
>>>
>>> Any suggestions on how to fix this?
>>
>> Either link to libatomic from recent gcc, or switch target cpu to something
>> that is pentium or newer. I doubt that it is reasonable to run GHC on 486.
>
> By switching target CPU you mean passing -march=pentium?
Some ports use this:
.include
[...]
.if ${ARCH} == i386 && empty(CFLAGS:M-march=*)
CFLAGS+=-march=i586
.endif
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Sat, Aug 08, 2020 at 12:37:42PM +0400, Gleb Popov wrote: > On Sat, Aug 8, 2020 at 1:29 AM Konstantin Belousov > wrote: > > > On Fri, Aug 07, 2020 at 08:42:12PM +0400, Gleb Popov wrote: > > > Hello toolchain@ > > > > > > I'm testing a new release of GHC (Haskell compiler) and it fails to link > > to > > > i386 architectures with > > > > > > > > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-install/build/ > > > libHSghc-prim-0.6.1-ghc8.10.1.so: undefined reference to > > `__atomic_store_8' > > > > > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-install/build/ > > > libHSghc-prim-0.6.1-ghc8.10.1.so: undefined reference to > > `__atomic_load_8' > > > > > > Any suggestions on how to fix this? > > > > Either link to libatomic from recent gcc, or switch target cpu to something > > that is pentium or newer. I doubt that it is reasonable to run GHC on 486. > > > > By switching target CPU you mean passing -march=pentium? For code generated by gcc or clang, yes. If the reference to the symbol was generated by ghc, then I do not know. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Sat, Aug 8, 2020 at 1:29 AM Konstantin Belousov wrote: > On Fri, Aug 07, 2020 at 08:42:12PM +0400, Gleb Popov wrote: > > Hello toolchain@ > > > > I'm testing a new release of GHC (Haskell compiler) and it fails to link > to > > i386 architectures with > > > > > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-install/build/ > > libHSghc-prim-0.6.1-ghc8.10.1.so: undefined reference to > `__atomic_store_8' > > > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-install/build/ > > libHSghc-prim-0.6.1-ghc8.10.1.so: undefined reference to > `__atomic_load_8' > > > > Any suggestions on how to fix this? > > Either link to libatomic from recent gcc, or switch target cpu to something > that is pentium or newer. I doubt that it is reasonable to run GHC on 486. > By switching target CPU you mean passing -march=pentium? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Undefined reference to __atomic_store_8
On Fri, Aug 07, 2020 at 08:42:12PM +0400, Gleb Popov wrote: > Hello toolchain@ > > I'm testing a new release of GHC (Haskell compiler) and it fails to link to > i386 architectures with > > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-install/build/ > libHSghc-prim-0.6.1-ghc8.10.1.so: undefined reference to `__atomic_store_8' > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-install/build/ > libHSghc-prim-0.6.1-ghc8.10.1.so: undefined reference to `__atomic_load_8' > > Any suggestions on how to fix this? Either link to libatomic from recent gcc, or switch target cpu to something that is pentium or newer. I doubt that it is reasonable to run GHC on 486. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
