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

[Janne Blomqvist <blomqvist.janne@gmail.com>]

On Tue, Jan 23, 2024 at 11:09 AM FX Coudert <fxcoudert@gmail.com> wrote:
>
> Hi Steve,

Hello, long time no see.

> 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.


-- 
Janne Blomqvist