From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by sourceware.org (Postfix) with ESMTPS id 4CF7D3857C70; Wed, 24 Jan 2024 19:28:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4CF7D3857C70 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=troutmask.apl.washington.edu Authentication-Results: sourceware.org; spf=none smtp.mailfrom=troutmask.apl.washington.edu ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4CF7D3857C70 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=128.95.76.21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706124518; cv=none; b=ZpB2xBYblYQ00KQ7aziapllxFo69Hs4+Y/vSTOKMHLmPmKfeAsUyQQ+dEZn4RN3/XoPUAoil6Q/QPyNjvwEPT//EGHSmiuVFHUjG0gdD3qNMbSd9mbqkvAv7DReWvNNTm6dhLs13Xb8oWJJP3IdjPCa4fRj5Z2w3Rtmt7I/+ltk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706124518; c=relaxed/simple; bh=4idOfU8CkIHvsSrThFhWagy25YTqvvRAEMvKD4MAOgA=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=IYIk/IdEXMIlAVva7giTdsbT5ist6awmTLXespCzMpw0CJE8f9Glr2hxPjhVDQD6u+bO5Ck1cYqEsAQOdTen1tKRuQgrcRAjNGayrNlhbOA2OHv+dMj2NQZNjWLNfCbfYo26ayamfg1KLqlLnlQkOZutw1DMzhjNSL02GOaJ2M8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 40OJSYG5061108; Wed, 24 Jan 2024 11:28:34 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 40OJSYG5061108 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1706124514; bh=4idOfU8CkIHvsSrThFhWagy25YTqvvRAEMvKD4MAOgA=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=G/MtXgZiP/YbV/rNIbjjz9qM2oAPgENYfdZwjZUXrlObdBkx3LTTEpppM+fM/6+s9 K0yXY0/mjHOuvhhztAS6Gz6ZJG7os75NJpbRmVKl/vs1BFW9IkQep1RzWm3zJVMGVU vDOLYuXYs4ntF4CghLDH+WFIL/sESkP71qAcVmirzlfrzvn4rRxw4KFGPV+V+fDA+Q jn5CUBYVoOylxtBAy76H2opLissNEZOC9eup1v0DjAc69rybJA58Ab04c+cMhLkcqg CoUSjw/AfCVtoG0gnzGQQdYxTKWDaU2/Uh3G/aA4d/8mWjILA7vpevYLykIRDCDEUz meEtFQeydALzw== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 40OJSY2p061107; Wed, 24 Jan 2024 11:28:34 -0800 (PST) (envelope-from sgk) Date: Wed, 24 Jan 2024 11:28:34 -0800 From: Steve Kargl To: Janne Blomqvist Cc: FX Coudert , fortran , gcc-patches@gcc.gnu.org Subject: Re: [Fortran] half-cycle trig functions and atan[d] fixes Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <0840023D-FF1D-47B5-B75F-806913399880@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_INVALID,DKIM_SIGNED,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Jan 24, 2024 at 11:13:05AM +0200, Janne Blomqvist wrote: > On Wed, Jan 24, 2024 at 10:28 AM FX Coudert wrote: > > > Now, if > > > the OS adds cospi() to libm and it's in libm's symbol map, then the > > > cospi() used by gfortran depends on the search order of the loaded > > > libraries. > > > > We only include the fallback math functions in libgfortran when they are not available on the system. configure detects what is present in the libc being targeted, and conditionally compiles the necessary fallback functions (and only them). > > Exactly. However, there is the (corner?) case when libgfortran has > been compiled, and cospi() not found and thus the fallback > implementation is included, and then later libc is updated to a > version that does provide cospi(). I believe in that case which > version gets used is down to the library search order (i.e. the order > that "ldd /path/to/binary" prints the libs), it will use the first > symbol it finds. Also, it's not necessary to do some ifdef tricks > with gfortran.map, if a symbol listed there isn't found in the library > it's just ignored. So the *pi() trig functions can be unconditionally > added there, and then depending on whether the target libm includes > those or not they are then included in the exported symbol list. > > It's possible to override this to look for specific symbol versions > etc., but that probably goes deep into the weeds of target-specific > stuff (e.g. are we looking for cospi@FBSD_1.7, cospi@GLIBC_X.Y.Z, or > something else?). I'm sure you don't wanna go there. > Ah, so that's the part I was missing. I was under the impression that if a symbol appears in a libraries symbol map, then the library had to contain a function by that name. If the loader ignores symbols for a missing function, then yes, I think I can get rid of the indirection via _gfortran_cospi_r4(). It will take a few days for me to redesign this, which shouldn't be too problematic in that GCC is in stage 4 and this is neither a regression or doc fix. Janne, FX, Harald, thanks for taking a peek. -- Steve