Re: [Fortran] half-cycle trig functions and atan[d] fixes

[Steve Kargl <sgk@troutmask.apl.washington.edu>]

On Tue, Jan 23, 2024 at 01:37:54PM +0200, Janne Blomqvist wrote:
> On Tue, Jan 23, 2024 at 11:09 AM FX Coudert <fxcoudert@gmail.com> 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