[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 #16 from dave.anglin at bell dot net ---
On 2020-04-15 2:14 p.m., sgk at troutmask dot apl.washington.edu wrote:
> It likely is the start of an approach, but it seems hpux is conflating 
> long double and __float128, where it flips between an 'l' and 'q' suffix.
> gfortran simply assumes a correspondence with C types and C99 naming
> conventions (e.g., sinf, sin, and sinl).  If a target has REAL(4), REAL(8),
> REAL(10), and REAL(16) the correspondence is float, double, long double,
> and __float128, respectively.  If a target has REAL(4), REAL(8), and REAL(16),
> then the correspondence is float, double, and long double.  There is no
> __float128, and by extension, no functions with a 'q' suffix.  The long
> double math function will end in 'l'.
It's not hpux conflating long double and __float128.  On hppa, there's a IEEE
128-bit float type
defined in the architecture and a limited set of arithmetic routines available
to manipulate this type.
There's no C99 support until HP-UX 11i version 2.  Even then, no long double
routines were implemented
for PA-RISC.

IA64 has REAL(10). There's routine for both double extended (w) and  long
double (l).  Initially, the
REAL(10) type was __float80.  REAL(16) on IA64 is quad (q).  __float128 is not
used by HP-UX.

There's no REAL(10) or REAL(16) on hppa.  Treating REAL(16) as __float128 was
my choice some years
ago.  It seemed compatible with gcc's __float128 on IA64 and I wanted to take
advantage of libquadmath
if possible.