add _HAVE_LONG_DOUBLE flag, math.h update

[Jeff Johnston]

Craig,

Have you looked at how glibc handles the constants?  Take a look at 
bits/nan.h bits/huge_val.h, bits/inf.h which use builtin first, then a 
GNUC extension, and failing that, a static union.  For the 2nd attempt, 
my headers have __mode__(__SI__) used.  I do not know if this is 
guaranteed for all platforms.  I prefer their logic to a divide by 0.

Regarding the old externs, keep them.  Some code may need them for 
linking back-level code.  They are harmless if not being used.

-- Jeff J.

Howland Craig D (Craig) wrote:
> The attached patch (ChangeLog included) adds a new configuration check
> at the top level to define _HAVE_LONG_DOUBLE in newlib.h when the long
> double type is present in the compiler.
>  
> While this change was being done, the checks for _LDBL_EQ_DBL and
> INIT_ARRAY (aka .init_array, etc.) were updated to only compile their
> test programs, rather than linking them, so that they will be more
> likely
> to work with cross compilers.  (The previous versions did not work for
> me with Xilinx PPC, but do now.  Also verified with native Cygwin.)
>  
> math.h receives two tweaks, both being related to some defines that
> either use GCC builtins (GCC >= 3.3) or "hand-done" values, specifically
> related to the hand-done case:
> 1)  The missing INFINITY and NAN defines are added.
> 2)  The HUGE_VAL set of defines as they were violated the standard, not
> being constant expressions, but pointing to a set of globals (defined
> in libm/common/s_infconst.c).  These are changed to legitimate constant
> expressions.  (I only have various GCC versions to test them with.  So
> while these should also work with other compilers, it is presently
> untested.)
>  
> The manner in which the now-unused __infinity defines in
> libm/common/s_infconst.c were done was not very portable, using integer
> values that depend on the size of float, double, and long double.  These
> were replaced with portable versions.  Since this new technique uses
> floating-point values for the initialization assignments, the order of
> the associated structures in math.h was changed.
>  
> QUESTION:  Despite the __infinity set of values being a library internal
> and now longer used, I did not delete them just in case some user code
> points to them directly.  Any user code that does this would be poor
> programming practice, of course, as the HUGE_VAL defines are what should
> be used.  Should we just go ahead and delete them now, or should they be
> left hanging around?  (I propose that deleting them now makes the
> most sense.  This would delete the libm/common/s_infconst.c source file,
> as well as the three similar __[fdl]math unions in math.h.  If this is
> the consensus, I'll provide an updated patch.)
>  
> Craig
>