On Tue, Jan 23, 2024 at 11:09 AM FX Coudert <fxcoud...@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
