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.
