add _HAVE_LONG_DOUBLE flag, math.h update
Wed May 6 09:14:00 GMT 2009
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
> 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
> 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.)
More information about the Newlib