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 966D83858C50; Tue, 23 Jan 2024 14:40:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 966D83858C50 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 966D83858C50 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=1706020834; cv=none; b=HyG+6/CZ8HUo11drP8fiahzDirjlGKWFQMdEpRs2nE8af1lGp03NDsVynbYQqBOUVhctdLBn0BbbO4CPplXA7XbIC5shhjRm9UOZcqfZyvPeSCB7TvnwCiLos/A8DYHtcV/OmH2ZKW0PsgB+VZGfhkHI7tiX0uRQ/D9+TreYhJc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706020834; c=relaxed/simple; bh=3JgrsOY8hFdL9mRsxL0X6bETdGlNAlKcQTxd1J9Qu+c=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=IfssSUgsARwHl0QaO+Mx779IjrNba0MNRZFlrHVkYsezBkOOrjB9uvrNK/PbRfs8Z0ICKHv3AM7rC0vs+HFhCBdltEzBdLSi80OVWW45YtfcR7e85gHyLE/pzSSQf6bi3J2Qs2oVFCvLjhCH4RTkQDQHe+bobUkf9A7+n2QxFAw= 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 40NEeRm9051620; Tue, 23 Jan 2024 06:40:27 -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=1706020827; bh=3JgrsOY8hFdL9mRsxL0X6bETdGlNAlKcQTxd1J9Qu+c=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=iar6eDL1v9bBXUZVpQ9x30LEuQy3m8VutRBhlcIyhmErSN17q4ZukgXk8YFifhGep juKNXz+vDhH7bK8tT7yObgF74QBjDR/b/NWbg6nX2kEIfzhxf/PUtKJCKompZJmAZt p+cPj4K603V2qYPNmXxRH9zASs3ZQ6G/9VKhrelgia0zOmWOp2lziVZqcm96bbPrfe 78hMYKSKZSf9AsQb80BUBcnuPOpGM7drmPOMZks2whfxlgoTFDboWXyJYQ0yL+g4gX 8IV0LrYal2oQPQOCSHbVq6mTJHwDfV/UpKjvtuVV2o+t6AGidFkwS627zQy5k6zu+W DoB+89SZ5xu/w== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 40NEeRWi051619; Tue, 23 Jan 2024 06:40:27 -0800 (PST) (envelope-from sgk) Date: Tue, 23 Jan 2024 06:40:27 -0800 From: Steve Kargl To: FX Coudert Cc: 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 10:08:43AM +0100, FX Coudert wrote: > Hi Steve, > > 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? Yes. cospi, sinpi, and tanpi are in IEEE754-2008. These are also in ISO/IEC TS 18661-4 along with acospi, asinpi, and atanpi, which I believe where merged into C23 (see n3096.pdf). I've checked if atan2pi is in C23, but it is in F2023. AFAIK, FreeBSD's libm is the only OS that contains cospi, sinpi, and tanpi. The arc functions haven't been written/committed, because something like cospi(x) = cos(x) / pi with pi split into hi-lo parts is good enough. > - On systems where libquadmath is used for _Float128, does > libquadmath contain the implementation of the q() variants for > those functions? AFAIK, libquadmath does not have the half-cycle functions. I wrote the function trig_fallback2.F90 to deal with REAL(16) (and maybe REAL17). > - 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. Yes, that is correct. I tried to install __builtin_acospif in trans-intrinsic to generate a direct call to acospif, but that led to many hours/days of frustration. I gave up. > 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? I gave up on that approach when I got some real obscure error about some math function which I did not touch. > - 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 precision of the fallback routines isn't too bad. More later today. Late for a doctor's approintment. -- Steve