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.
