From owner-freebsd-toolchain@freebsd.org Tue Aug 11 21:52:14 2020 Return-Path: Delivered-To: freebsd-toolchain@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1399B3B7F74 for ; Tue, 11 Aug 2020 21:52:14 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4BR64Y6b9Tz462s for ; Tue, 11 Aug 2020 21:52:13 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id E1EC43B8567; Tue, 11 Aug 2020 21:52:13 +0000 (UTC) Delivered-To: toolchain@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E1B013B860A for ; Tue, 11 Aug 2020 21:52:13 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay117.isp.belgacom.be (mailrelay117.isp.belgacom.be [195.238.20.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign RSA OV SSL CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BR64Y3HRgz46DK; Tue, 11 Aug 2020 21:52:13 +0000 (UTC) (envelope-from tijl@freebsd.org) IronPort-SDR: ndSedAMx9515qm5TBm7wI1DP6Dk3FYxK7VRCSt5MkiDh9FhFhDRlDDukxS1SGhhqRQk/ztuNTJ EV0Z44ZfZIyvIwDUCNqmQPE3MCB/ThyP/tfdNdwpg+ouwrF2h+2CgtyYdcOiWP4rjtZRli/uXB yslT8YVhSfNLoWG3/7Quh/2KkA81b2jfBSycFRoQbdUOUzSn3whwW9lkifpDKxJQ1/14DevSIn YhO0EyQrtmbfDPIpL4jm0OcVgwW0+4CaaovlZLjq99Rt8BDhJjTxPBUYU7ESQSMs1FluHcg9wQ j58= X-Belgacom-Dynamic: yes IronPort-PHdr: =?us-ascii?q?9a23=3AJ3AsIREo1aRgfNNlkjqWR51GYnF86YWxBRYc79?= =?us-ascii?q?8ds5kLTJ7ypcmwAkXT6L1XgUPTWs2DsrQY0rSQ4vmrATVIyK3CmUhKSIZLWR?= =?us-ascii?q?4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBx?= =?us-ascii?q?rwKxd+KPjrFY7OlcS30P2594HObwlSizexfLJ/IA+yoAnMucUanZZuIbstxx?= =?us-ascii?q?XUpXdFZ/5Yzn5yK1KJmBb86Maw/Jp9/ClVpvks6c1OX7jkcqohVbBXAygoPG?= =?us-ascii?q?4z5M3wqBnMVhCP6WcGUmUXiRVHHQ7I5wznU5jrsyv6su192DSGPcDzULs5Vy?= =?us-ascii?q?iu47ttRRT1jioMKjw3/3zNisFogqxVoAyvqQF8zYHWboGaO+ZxcKzGcNMGR2?= =?us-ascii?q?dMRNpdWzBdDo+iaYYEEuoPPfxfr4n4v1YAsx68BQ2xD+7xzT9IgWT20rM/0+?= =?us-ascii?q?s7FwHGxxErEtUSsHTVrtX1MLwfX+CvzKbW0zrOcu5Y1znn5IjPaBAhruiBUL?= =?us-ascii?q?RtesXe1UchDRnKjkmMqYP7JTOV0PwAvnaF4uZ9S+6ilWAqpgFxrzavxsohhY?= =?us-ascii?q?fEiIwWx13a8Sh0wYQ4KN2kRUNmYdCpEJhduj+EOoZ4Tc4vR2BltDg0xLAApJ?= =?us-ascii?q?W1fzAKxYwkyhLCcfCLbYeF7g75WOueIzp0nm9pdba7ihu07EOu0PfzVtOu31?= =?us-ascii?q?ZPtidFl97MuW0T2BHL8ciHT+d9/l+m2TaSywDf8uFELl4wlarcM5MhwaQ/lp?= =?us-ascii?q?4SsUTGACD2gkL2gLWKdkUl+Oio7/7rbanhpp+bLI97lAT+Pb4omsykG+g4NR?= =?us-ascii?q?IOX2eD9eS90r3s41H5Ta1Jg/EriKXVrp/XKdgBqqO2AQJZyJsv5hK7Aju+1d?= =?us-ascii?q?QXh3gHLFZLeBKdiIjpPknDIOz5Dfe9h1Shizlrx+rYMbL/GZrNNWXMnK3mfb?= =?us-ascii?q?Zn5E5Q0BAzwsxH55JIFrEBJ+r+WlP2tNzfCh82Lwy0zPzmCNV7zY4eV3iPDb?= =?us-ascii?q?GHP6zJql+H+/gjI+6WZI8aoDz9MeQq5+byjX8lnl8QZaqp3ZwMaHCkH/RmIF?= =?us-ascii?q?6WbmTogtoaHmcKuxAxTO3uiFGYTTFTYHOyVbom5j4nEIKmEZvDRoe1jbObxi?= =?us-ascii?q?e7BJpWZ25bBV2XH3fobZuLVOkXZyKJP8BtiDsEVaKuS9xp6Rb7mwv3wfJfKf?= =?us-ascii?q?LT5GVMvIj508d5z+PJmBw47jAyCN6ShTKjVWZxy1/vQ3cd26dkrEl0zEzLhb?= =?us-ascii?q?R5gfhwO8Ze6tlyfkE9L5GKnL8yMMz7Rg+UJoTBc12hWNjzWTw=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DWAgBYEjNf/8cv8FFgHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAB4EyBAEBCwEBgwMUVAFJFY03hguCEIhigSV/iWCHKwsBAQE?= =?us-ascii?q?BAQEBAQEjFAQBAYRMAoI0JTcGDgIDAQEBAwIFAQEGAQEBAQEBBQQBhg85DEM?= =?us-ascii?q?BAQQLAYFiIoMZAQU6HCMQCw4FBS4hNgYTgyeCSwMysm2BNIVSglYNgR2BBYE?= =?us-ascii?q?4AY0pggCDbDU+ghqIGgSSPohdmjxRgmyIY4w5hG4woBUtnyOUJIF7TTAIgyQ?= =?us-ascii?q?JRxkNkTKLNj8DMDcCBggBAQMJgm+CO4t5AQE?= X-IPAS-Result: =?us-ascii?q?A2DWAgBYEjNf/8cv8FFgHAEBAQEBAQcBARIBAQQEAQFAB?= =?us-ascii?q?4EyBAEBCwEBgwMUVAFJFY03hguCEIhigSV/iWCHKwsBAQEBAQEBAQEjFAQBA?= =?us-ascii?q?YRMAoI0JTcGDgIDAQEBAwIFAQEGAQEBAQEBBQQBhg85DEMBAQQLAYFiIoMZA?= =?us-ascii?q?QU6HCMQCw4FBS4hNgYTgyeCSwMysm2BNIVSglYNgR2BBYE4AY0pggCDbDU+g?= =?us-ascii?q?hqIGgSSPohdmjxRgmyIY4w5hG4woBUtnyOUJIF7TTAIgyQJRxkNkTKLNj8DM?= =?us-ascii?q?DcCBggBAQMJgm+CO4t5AQE?= Received: from 199.47-240-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.240.47.199]) by relay.skynet.be with ESMTP; 11 Aug 2020 23:52:12 +0200 Received: from localhost (localhost [127.0.0.1]) by kalimero.tijl.coosemans.org (8.16.1/8.16.1) with ESMTP id 07BLqAaE085106; Tue, 11 Aug 2020 23:52:10 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Tue, 11 Aug 2020 23:52:10 +0200 From: =?UTF-8?B?VMSzbA==?= Coosemans To: Gleb Popov Cc: Konstantin Belousov , toolchain@freebsd.org Subject: Re: Undefined reference to __atomic_store_8 Message-ID: <20200811235210.41049ad1@FreeBSD.org> In-Reply-To: References: <20200807212855.GB2551@kib.kiev.ua> <20200808133000.GC2551@kib.kiev.ua> <20200809143742.430764e7@FreeBSD.org> <20200809154312.GH2551@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4BR64Y3HRgz46DK X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:5432, ipnet:195.238.0.0/19, country:BE]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 21:52:14 -0000 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.