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

["joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-11-26 21:28:52 UTC ---
On Fri, 26 Nov 2010, dave at hiauly1 dot hia.nrc.ca wrote:

> I needed to add __float128 type and some builtins.  To do this, I

__float128 should only be present where it is distinct from long double; 
it just confuses things to add it on other architectures.

> 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?

No.  The purpose of libquadmath is to provide functions for the __float128 
type which is not a standard C type, for targets where it is present as a 
fourth floating-point type.  It is not to substitute for deficiencies in 
the system libm regarding functions for the standard three types.

If you wish to create a substitute or add-on libm for standard functions 
for the standard types where system libm is missing them, discuss that on 
the mailing lists, not in a Bugzilla PR.  It should not be libquadmath; it 
should be called something else, although it might share some source 
files.  The source files would in that case be adapted to abstract away 
the name of the type involved, so they can be built for either __float128 
or long double.