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 1476B3858D3C; Tue, 23 Jan 2024 17:30:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1476B3858D3C 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 1476B3858D3C 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=1706031061; cv=none; b=X1XrnoYIWZk1BQp7MsdrPH3hsQR2rQ7ofZcMs4vTaGxKcQuDe/zJMGcJuauW/FL2xnFh9+ewFmfPH8MY8HwpzggQJXhoKufqxoal2XBJfRkFzyaIY4Ov3E7FQgurZZmTwf1IFNca0t7WCQ+2uQzlgzxOtd/jfZYlRGNsZQtpbs4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706031061; c=relaxed/simple; bh=QZWw1i2kWeQv2kINqj4yFeljFVQ63ExxAFhcHMpBhUg=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=Uj9nke/5eJeGqx6YUxFmcNFC4h+R5DLLY5tM3JygyLu9hYHRIZ+EJ4XpS80Ix5mbHaxSSmVqreiYwUesBI45OcnnfjiZbLnTpX7WT3wO8jwCYnmCNslOVS0DJCplloBVkME6n3oFcFIOY8eL6yOzP8h+CqVBiPNrUV/TFY9nmN8= 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 40NHUxHd052688; Tue, 23 Jan 2024 09:30:59 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=myselector-troutmask; t=1706031059; bh=QZWw1i2kWeQv2kINqj4yFeljFVQ63ExxAFhcHMpBhUg=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=nAzU9awVKf4UXUSlOm+B5XnSCNF5fQd9BMQ/h/ZmXfwicTMu0uW374+bcugjcKv5r ixy2beJS3FWEd6UI1E8PPAgtOrfKzqiPtwv9zMCM3qqAZae9qs7L46Ad/gcAFm/oN6 zFfit1M9ivXhbfhVRU9Lokr12s/jfV+B7L6YnbDOs4yvjHx7FI7BlIUPi9QOWxdLwO R+z4G8KgaMYFvBbObCyqpgF6Vqq6NK0Ye4TFAC7kiPtRgbbrbcS6PO08/ciDq06+8b DVfZe5u1qx1aZ+OWP9mgtFm6TviQ+Von0MzOSSMswaHUTNGS7TJ16Oqq4iKGisv745 lI3AzyykUgO+A== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 40NHUxhq052687; Tue, 23 Jan 2024 09:30:59 -0800 (PST) (envelope-from sgk) Date: Tue, 23 Jan 2024 09:30:59 -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=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 Tue, Jan 23, 2024 at 01:37:54PM +0200, Janne Blomqvist wrote: > On Tue, Jan 23, 2024 at 11:09 AM FX Coudert wrote: > > > > Hi Steve, > > Hello, long time no see. Time is short and we're all busy with life, but it is nice to see familiar names! > > > Thanks for the patch. I’ll take time to do a proper review, but after a first read I had the following questions: > > > > - "an OS's libm may/will contain cospi(), etc.”: do those functions conform to any standard? Are there plans to implement them outside FreeBSD at this point? > > acospi, asinpi, atan2pi, atanpi, cospi, sinpi, tanpi are all in IEEE > 754-2019, and are slated to be part of C23. I would assume actively > developed libm's will eventually catch up and implement them. > > > - 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. > > > - On most targets, cospi() and friends are not available. Therefore, we end up doing the fallback (with limited precision as you noted) but with a lot of indirection. We could generate that code directly in the front-end, couldn’t we? > > The frontend generally doesn't know what the target libm implements, > hence it's better to just generate the call, and if necessary have a > barebones implementation in libgfortran if libm doesn't implement it > properly. > I suppose I could add a gfc_conv_trigpi() to trans-intrinsic.c, which could be used emit the function calls directly. Give me until Saturday to look at the issue. I've finally understood what Harald has been trying to tell me about the MPFR version issue in bugzilla, so I need to revamp simplification. -- Steve