From owner-freebsd-toolchain@freebsd.org Sun Aug 9 15:43:27 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 1FE353B7E88 for ; Sun, 9 Aug 2020 15:43:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4BPjzy6R48z497L for ; Sun, 9 Aug 2020 15:43:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id DAED73B7E87; Sun, 9 Aug 2020 15:43:26 +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 DAB373B7CAA for ; Sun, 9 Aug 2020 15:43:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BPjzy1h67z4906; Sun, 9 Aug 2020 15:43:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 079FhCij047475 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 9 Aug 2020 18:43:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 079FhCij047475 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 079FhCgm047474; Sun, 9 Aug 2020 18:43:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 9 Aug 2020 18:43:12 +0300 From: Konstantin Belousov To: =?utf-8?Q?T=C4=B3l?= Coosemans Cc: Gleb Popov , toolchain@freebsd.org Subject: Re: Undefined reference to __atomic_store_8 Message-ID: <20200809154312.GH2551@kib.kiev.ua> References: <20200807212855.GB2551@kib.kiev.ua> <20200808133000.GC2551@kib.kiev.ua> <20200809143742.430764e7@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200809143742.430764e7@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4BPjzy1h67z4906 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] 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: Sun, 09 Aug 2020 15:43:27 -0000 On Sun, Aug 09, 2020 at 02:37:42PM +0200, 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. 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. 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.