https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
Bug ID: 113152
Summary: Fortran 2023 half-cycle trigonometric functions
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: kargl at gcc dot gnu.org
Target Milestone: ---
Created attachment 56949
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56949&action=edit
patch with implementation
The attach patch implements the half-cycle trigonometric functions that
are now contained within Fortran 2023. There a few things to note.
1) IEEE 754-2008, ISO/IEC TS 18661-4, C23, and Fortran 2023 all contain
these functions. This likely means that the functions acospi(), asinpi(),
..., tanpi() may be available as part of an operating system's libm. In
fact, FreeBSD has implementations of cospi, sinpi, and tanpi in libm, and
these conform to the requirements of IEEE 754-2008 and ISO/IEC TS 18661-4.
The file libgfortran/intrinsics/trigpi_fallback1.c provides fallbacks for
float, double, and long double functions. As I don't know the internals
for libquadmath or ibm double-double, the REAL(16) (and GFC_REAL_17)
fallback functions are in libgfortran/intrinsics/trigpi_fallback1.F90.
I have tested REAL(16) that sits on top of libquadmath. I have not tested
the double-double situation. Finally, the fallback functions do not go
to any length in meeting all of the requirements of IEEE 754-2008. For
example, sinpi(n+0.5) is exactly +-1 for representable integer n. The
fallbacks may raise an FE_INEXACT exception.
2) I tried adding math builtins in gcc/fortran/mathbuiltins.def to directly
map to libm functions, but this ultimately led to much frustration. I gave
up and wrap, for example, cospi() in _gfortran_cospi_r8(). So, there is a
level of in-direction. This is done in libgfortran/intrinsics/trigpi.c.
Someone smarter than I can do the math builtins.
3) I tried inserting GFC_ISYM_ACOSPI, ..., GFC_ISYM_TANPI in alphabetical
order in 'enum gfc_isym_id' of gfortran.h. This runs into some obscure
issue with libgomp where C_ASSOCIATED is no longer recognized. So, I
placed the new members of the enum at its end.
4) I don't use git. I tried to do 'git add libgfortran/intrinsics/trigpi\*'
followed by 'git commit libgfortran/intrinsics/trigpi\*', and then
finally 'git diff > z_halfcycle.diff'. This does not generate one
unified diff file. Sigh. I'll attach the new files along with the
mangled diff.
