On Tue, 11 Aug 2020 15:56:35 +0400 Gleb Popov <arr...@freebsd.org> wrote: > On Sun, Aug 9, 2020 at 7:43 PM Konstantin Belousov <kostik...@gmail.com> > 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"
