[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)

["dave at hiauly1 dot hia.nrc.ca" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46584

--- Comment #5 from dave at hiauly1 dot hia.nrc.ca 2010-11-26 19:04:56 UTC ---
On Fri, 26 Nov 2010, burnus at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46584
> 
> --- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-26 08:04:50 UTC ---
> The test case quad_1.f90 does not always use quad precision (despite its name)
> but it uses the highest available floating point type. Depending on the system
> that can be the real kind 8 (64 bits), 10 (80 bits) or 16 (128 bits).
> 
> The FE does the following matching for a REAL type matching sizeof(float) ->
> "sinf", for double -> "sin", for long double -> "sinl", and for __float128 ->
> sinq.
> 
> Thus, on HPPA there seems to be a floating point type which is larger than
> "double" and which matches "long double" while __float128 does not seem to be
> available.
> 
> Hence, the issue seems to rather that we have found a C99 math function which
> is no implemented in HPUX: A long-double complex cosine (ccosl).
> There are some fall-back C99 functions implemented in libgfortran but seemingly
> none of the complex trigonometric ones; cf.
> http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgfortran/intrinsics/c99_functions.c
> 
> The muddle over solution is to change the ccosl function to some other -
> possibly complex - long double function which is implemented - maybe csqrtl is?
> 
> 
> > I have a patch that adds the hooks to build libquadmath on PA HP_UX targets. 
> > However, I'm not sure what's the best way to map the 'l' C99 builtins like
> > those below to the corresponding 'q' functions in the new library.
> 
> It is not completely clear what your patch is supposed to do. Seemingly PA has
> a hardware >(8 bytes)/double data type. I do not know whether long double is 80
> bits long or 128 bits. If it is not 80 bits, you could consider adding
> __float128 - but if long double is already 128 bits, I do not see why one
> should do so.  If there is no 128 bit type, adding __float128 will
> automatically make a REAL(16) available, which will use libquadmath.

PA has hardware float and double.  The architecture has provision
for long double but this was never implemented in hardware.  HP-UX
has a software support for for basic arithmetic and compares using
long doubles.  However, there are now math routines of any kind.

The original testcase failure occured with the existing long double
support because of the lack of long double math routines (cosl, etc).

Given the recent addition of libquadmath, I thought it might be useful
to try and enable it.  Current patch to enable building libquadmath
is attached.  libquadmath appears to have built successfully on
hppa64-hp-hpux11.11 with this change.

I needed to add __float128 type and some builtins.  To do this, I
essentially copied stuff from ia64.  As things stand now, it seems
the fortran front end uses the 'l' math functions in preference to
the 'q' functions in libquadmath.

It appears the configure for libgfortran checks for the presence
of all the 'l' math functions.  However, it might be better to map
'l' to 'q' in a quadmath header, so libquadmath doesn't depend on
libgfortran (i.e., make it usable from C, etc).

Does this make sense?

Dave