This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: add _HAVE_LONG_DOUBLE flag, math.h update
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