[PATCH, libgfortran] Protect the trigd functions in libgfortran from unavailable math functions [PR94586, PR94694]

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[PATCH, libgfortran] Protect the trigd functions in libgfortran from unavailable math functions [PR94586, PR94694]

gcc - fortran mailing list
This patch here is a follow-on to Jakub's in his message "[PATCH]
libgfortran: Provide some further math library fallbacks [PR94694]" at
https://gcc.gnu.org/pipermail/fortran/2020-April/054252.html.

I think this should be committed along with Jakub's patch in response
to PRs 94586 and 94694. Though this patch alone does not fix either
PR, it prevents the build from failing when the degree-valued
trigonometric functions are ultimately unavailable on the target due
to lack of math library builtins.

If HAVE_* is not defined for the math functions required by the trigd
implementations, the intrinsic functions are built only to throw a
runtime_error. Prior to this, the libgfortran build would fail
completely. These intrinsics are extensions, and before the original
trigd patch the library could build even when these math functions
were missing. Therefore, I think the compiler should not fail to build
simply because the intrinsics are unsupported on the target.

In theory, this patch would also fix the trigd build for targets which
don't have a floating-point INFINITY defined, though I am unsure if
any such targets exist.

Furthermore, this patch replaces hard-coded floating point literal
suffixes with the use of GFC_REAL_<kind>_LITERAL_SUFFIX, as defined by
libgfortran's kinds.h. This could help targets with quirky definitions
for real(16) such as HPUX, as in PR 94586. Similarly, the precision
used for the constants COSD_SMALL, COSD30, et al. for the REAL(16)
case are derived from the precision of GFC_REAL_16 rather than its
long-double-ness, since for example on HPUX long double is actually
128 bits.

This patch also fixes an issue which could have occurred in the
front-end: the front-end attemped to use a host-sized floating-point
literal to represent cosine of 30 degrees. This is of course
nonsensical. The patch replaces this with the use of mpfr functions to
compute the value as sqrt(3)/2 to the correct precision. I include
this in the patch because it is also a target-specific issue with the
degree-valued trigonometric intrinsics.

Jakub has OK'd the patch and I recently authored the original trigd
code being modified here. After his patch is committed I will commit
this one unless others have comments or concerns.

libgfortran/ChangeLog:

2020-04-22  Fritz Reese  <[hidden email]>

    * intrinsics/trigd.c, intrinsics/trigd_lib.inc, intrinsics/trigd.inc:
    Guard against unavailable math functions.
    Use suffixes from kinds.h based on the REAL kind.

gcc/fortran/ChangeLog:

2020-04-22  Fritz Reese  <[hidden email]>

    * trigd_fe.inc: Use mpfr to compute cosd(30) rather than a host-
    precision floating point literal based on an invalid macro.

---
Fritz Reese

[Note: the only differences between this patch and the one in the PR
is whitespace.]

gcc10-pr94694-trigd-3.patch (27K) Download Attachment