[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'

["dave.anglin at bell dot net" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586

--- Comment #12 from dave.anglin at bell dot net ---
On 2020-04-15 11:02 a.m., sgk at troutmask dot apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
> 
> --- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
> On Tue, Apr 14, 2020 at 11:46:36PM +0000, dave.anglin at bell dot net wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
>>
>> --- Comment #10 from dave.anglin at bell dot net ---
>> On 2020-04-14 6:08 p.m., sgk at troutmask dot apl.washington.edu wrote:
>>> So, hppa64 has REAL(16), but it does not use __float128 or 
>>> GFC_REAL_16_IS_FLOAT128 is somehow not getting set.  Instead 
>>> of the above kludge you can do something like
>> It appears GFC_REAL_16_IS_FLOAT128 is not getting set.  Will investigate.
>> There's a similar problem with the test dec_math.f90 which has started to fail
>>
>> We have when the hpux long double library is available:
>>
>>       /* Under HPUX, the __float128 type is a synonym for "long double".  */
>>       (*lang_hooks.types.register_builtin_type) (long_double_type_node,
>>                                                  "__float128");
>>
>> We have __builtin_fabsq, __builtin_copysignq, __builtin_infq and
>> __builtin_huge_valq.
>> I suppose  I could add "l" versions.
>>
> 
> This seems to be confusing the simply assumptions in 
> libgfortran/kinds-override.h, which states
> 
> /* What are the C types corresponding to the real(kind=10) and
>    real(kind=16) types? We currently rely on the following assumptions:
>      -- if real(kind=10) exists, i.e. if HAVE_GFC_REAL_10 is defined,
>         then it is necessarily the "long double" type
>      -- if real(kind=16) exists, then:
>          * if HAVE_GFC_REAL_10, real(kind=16) is "__float128"
>          * otherwise, real(kind=16) is "long double"
>    To allow to change this in the future, we create the
>    GFC_REAL_16_IS_FLOAT128 macro that is used throughout libgfortran.  */
> 
> #if defined(HAVE_GFC_REAL_16)
> # if defined(HAVE_GFC_REAL_10)
> #  define GFC_REAL_16_IS_FLOAT128
> #  if !defined(HAVE_FLOAT128)
> #   error "Where has __float128 gone?"
> #  endif
> # else
> #  define GFC_REAL_16_IS_LONG_DOUBLE
> # endif
> #endif
> 
> So, hpux does not have REAL(10) and has REAL(16).  This is doing
> what it is designed to do based on the assumption that a target
> like hpux with REAL(16) will define the long double functions 
> with the 'l' suffix.  It seems the the fix for hpux is to change
> the test to something like 
> 
> # if defined(HAVE_GFC_REAL_10) || defined(__HPUX__)
> 
> using, of course, whatever the relevant macro.  This will then
> select the 'q' suffix.

I tried the above approach yesterday but it led to a couple of undefined
symbols in libgfortran that
caused a new test fail.  Possibly, the above might be a better overall approach
but this is what I ended
up doing last night:

diff --git a/libgfortran/intrinsics/trigd.c b/libgfortran/intrinsics/trigd.c
index 81699069545..970c60952ee 100644
--- a/libgfortran/intrinsics/trigd.c
+++ b/libgfortran/intrinsics/trigd.c
@@ -27,6 +27,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If
not, see

 #include <math.h>

+#if (_POSIX_VERSION < 200112L)
+#define fmaf(a,b,c) ((a)*(b)+(c))
+#define fma(a,b,c) ((a)*(b)+(c))
+#endif

 /*
    For real x, let {x}_P or x_P be the closest representible number in the
@@ -169,7 +173,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. 
If not, see
 #define COSD        cosd_r16
 #define TAND        tand_r16

-#ifdef GFC_REAL_16_IS_FLOAT128 /* libquadmath.  */
+#if defined(GFC_REAL_16_IS_FLOAT128) || !defined(HAVE_COSL) /* libquadmath. 
*/
 #define SUFFIX(x) x ## q
 #else
 #define SUFFIX(x) x ## l

This fixed build of trigd.c.  I think I need to do something similar to fix
dec_math.f90:

FAIL: gfortran.dg/dec_math.f90   -O0  (test for excess errors)
Excess errors:
/usr/ccs/bin/ld: Unsatisfied symbols:
   tanl (first referenced in /var/tmp//ccLGIJFM.o) (code)
   asinl (first referenced in /var/tmp//ccLGIJFM.o) (code)
   sinl (first referenced in /var/tmp//ccLGIJFM.o) (code)
   acosl (first referenced in /var/tmp//ccLGIJFM.o) (code)
   atanl (first referenced in /var/tmp//ccLGIJFM.o) (code)
   atan2l (first referenced in /var/tmp//ccLGIJFM.o) (code)
   cosl (first referenced in /var/tmp//ccLGIJFM.o) (code)

It's the only new fail.

It might be better to add configure checks for fmaf and fma.