Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Aug 2020 09:21:36 +0400
From:      Gleb Popov <arrowd@freebsd.org>
To:        =?UTF-8?Q?T=C4=B3l_Coosemans?= <tijl@freebsd.org>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, toolchain@freebsd.org
Subject:   Re: Undefined reference to __atomic_store_8
Message-ID:  <CALH631kJhO3LTYqHsd%2Bu0c_KNegQVaphbyhrbtTxGLkLHQ9s3w@mail.gmail.com>
In-Reply-To: <20200811235210.41049ad1@FreeBSD.org>
References:  <CALH631msD2jEwaH2ejzdE5RCYd=CA2GYV-o-%2BfC6sPSskXdkTg@mail.gmail.com> <20200807212855.GB2551@kib.kiev.ua> <CALH631=FxoEdp_akV-szxTuLVrZ4oFgHWKcWJNOGEuLwqJ3Hyw@mail.gmail.com> <20200808133000.GC2551@kib.kiev.ua> <CALH631nqdHq02xYM4cnOaPhmB5L3O5TJyZiKVNrUJu7kHg0uFQ@mail.gmail.com> <20200809143742.430764e7@FreeBSD.org> <20200809154312.GH2551@kib.kiev.ua> <CALH631=7M6J3L7AzgHqEwtyBo6f-9SPM4w3PDAULUACVwJMVyg@mail.gmail.com> <20200811235210.41049ad1@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 12, 2020 at 1:52 AM T=C4=B3l Coosemans <tijl@freebsd.org> wrote=
:

> On Tue, 11 Aug 2020 15:56:35 +0400 Gleb Popov <arrowd@freebsd.org> wrote:
> > On Sun, Aug 9, 2020 at 7:43 PM Konstantin Belousov <kostikbel@gmail.com=
>
> > wrote:
> >
> > > I do not believe there were any change in the toolchain between p2 an=
d
> p7,
> > > this is more likely indicates some fluctuation in the build.  The onl=
y
> > > 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/atom=
ic.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/g=
hcversion.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/inclu=
de
> > \
> >
> -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-derivedconsta=
nts/header
> > \
> >
> -I/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/includes/dist-install/build=
 \
> > -march=3Di686 -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 followin=
g
> > way:
> >
> > cc -U__i686 '-march=3Di686' -fno-stack-protector -DTABLES_NEXT_TO_CODE
> > '-march=3Di686' -x c
> >
> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atom=
ic.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/ghc=
version.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?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALH631kJhO3LTYqHsd%2Bu0c_KNegQVaphbyhrbtTxGLkLHQ9s3w>