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 A66B03858D37; Wed, 24 Jan 2024 06:21:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A66B03858D37 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 A66B03858D37 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=1706077264; cv=none; b=lh1eM4kVYpbOY8CXCRS3GFN0BpzVIMTYG5sSlROyxuXIRopEIk8R499Y5QsCYrwGR0kkVQkqIW99OyEmaKH3vxFoJ7eASFoS6Q+3yvwULexYMO/MoSpf36rN+L2A0teIAAR30G2u+xYzeFfSvVv/vhsT+pGbWeYdX8ZTBqR194s= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706077264; c=relaxed/simple; bh=3FALezNFUbCTHtvml+NLCNpjHucBa5Og4E1L2aOr/co=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=k+G/mUNM8Yb++960Dsf6RhSDIgBqPMcse/T+5+RIzdUVXIGeKooJgQ1S0DcFjqdSIiUOP/581DwbZ/a44fbCnPtfui0RiChfCKEF9LVdzwC4ZWTp3nsmTjwnhW3GzVBBkX6Vi007q130DSuOMp9HjF8RV4j4djLlvN81HGDxt60= 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 40O6L058058164; Tue, 23 Jan 2024 22:21:00 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 40O6L058058164 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1706077260; bh=3FALezNFUbCTHtvml+NLCNpjHucBa5Og4E1L2aOr/co=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=CFveVtPzuj7tP9jtcVbfPUs18Gn9cHcZhXcfkoqTxhup+dpxFq+/GJle7H7zVS67K trj+23/rJsTXBPWFsYQpYQuCaw6nC+z2LqpQstNOLSChB8KujOXdMZPFgIabjjI5/f +XYlZSUmkwFs+K9v0q5HvvnGEfzcNQib7rFU5u3bSpQldnBQRq3nN3a/g0DaEY9DLN zecFbTUH1P/m+OHqOJBtIlHYZvEgS7WxVyBqKuv+7WG5xy3BfTuIa83q4QRi0Hxt/8 +A4IrqHucADqpjgm4iFexwglOvnguhonYDl9gC8L0KRG1M4Aedj9/tId/kes3pn1rh U6riY3TPta6jQ== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 40O6L0M8058163; Tue, 23 Jan 2024 22:21:00 -0800 (PST) (envelope-from sgk) Date: Tue, 23 Jan 2024 22:21:00 -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: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 Tue, Jan 23, 2024 at 01:37:54PM +0200, Janne Blomqvist wrote: > > > - If I get this right, to take one example, the Fortran front-end will emit a call to gfortran_acospi_r4(), libgfortran provides this as a wrapper calling acospif(), which is called either from libm or from libgfortran. This is different from other math library functions, like ACOS() where the acosf() call is generated directly from the front-end (and then the implementation comes either from libm or from libgfortran). Why not follow our usual way of doing things? > > Good point, that's what we've done in c99_functions.c in libgfortran. > We should probably do this so we can skip jumping via libgfortran when > libm implements these directly. > Hopefully, FX sees this as my emails to gmail bounce. I don't see how this can work or I don't understand symbol versioning in libraries. If an OS does not supply cospi() in its libm, then gfortran will fallback to a cospi() in libgfortran. With the indirection I currently implement, cospi() is not in the symbol map of libgfortran and _gfortran_cospi_r4() will use the libgfortran version. 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. Consider on FreeBSD, I have % nm --dynamic /lib/libm.so.5 | grep cospi 0000000000025b60 T cospi@@FBSD_1.7 0000000000025fe0 T cospif@@FBSD_1.7 000000000002e230 T cospil@@FBSD_1.7 % nm --dynamic work/lib/libgfortran.so.5 | grep cospi 00000000002b1e60 T _gfortran_acospi_r10@@GFORTRAN_14 00000000002b4590 T _gfortran_acospi_r16@@GFORTRAN_14 00000000002b1d80 T _gfortran_acospi_r4@@GFORTRAN_14 00000000002b1df0 T _gfortran_acospi_r8@@GFORTRAN_14 00000000002b1ea0 T _gfortran_cospi_r10@@GFORTRAN_14 00000000002b46d0 T _gfortran_cospi_r16@@GFORTRAN_14 00000000002b1dc0 T _gfortran_cospi_r4@@GFORTRAN_14 00000000002b1e30 T _gfortran_cospi_r8@@GFORTRAN_14 U cospi@FBSD_1.7 U cospif@FBSD_1.7 U cospil@FBSD_1.7 The FE generates code for _gfortran_cospi_rXX. If FreeBSD adds say acospif() and libgfortran also exported, then how does the linker choose between acospif@@FBSD_1.7 and acospif@@GFORTRAN_14?. -- Steve