This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: long double (was "strtold?")


Hi Ken,

A number of comments:

1) Use _LONG_DOUBLE instead of long double everywhere
The PPC SPE for example redefines _LONG_DOUBLE to be double in sys/config.h
Other platforms are allowed to do this.
2) Put the _LDBL_EQ_DBL check in libc/include/machine/ieeefp.h
(fix the SPE to manually #undef and then #define it to true in sys/config.h)
3) Add a license for the new files. If it is copied from a file without a license, then mention which
file it is copied from or add the Red Hat license from COPYING.NEWLIB which is the
default license
4) If these functions will ever be implemented, they will probably end up in libm/math, not libm/common
If Craig doesn't mind doing this when he implements them, I have no objections.
5) Some docs would be nice at least to state the group is only available when long double == double


-- Jeff J.

Ken Werner wrote:
On Thursday 02 April 2009 00:32:45 Howland Craig D (Craig) wrote:
A few questions and two suggestions.

Why is the defined(__GNUC__) term included in the general #if that is
used?
(It was obviously needed in the previous aliasing approach, but I don't
see why it is present in this approach.)

My bad - this is a relict of the former patch. Thanks for the heads up.


Why do the libm source files all have w_ as a prefix?  (e.g. w_atanl.c)
(I have no idea why some of the existing source files are s_ and some
are
e_ and others are w_, along with other minor variations.  Do you know
the naming convention?)

Regardless of the w vs. s vs. e, the names are not consistent with what
is presently there for float with respect to double. For example,
s_atan.c and sf_atan.c. If we were to follow the existing convention,
it should be wl_atan.c, for example. Personally, I'd rather skip the
silly prefixes and just make it the function name, e.g. atanl.c. I
propose that we do without the prefixes, starting clean for all of the
long double routines (at least in libm, where the names were done that
way).

From looking at the sources it seems like w is for wrappers. Omitting the prefix sounds reasonable. In case a platform wants to override existing math routines there should be only one file for each routine. When implementing real long double routines we probably don't want them to be flagged as wrappers (assuming the overlay is done by matching the file names). The attached patch skips the prefix.


Should libm/common/Makefile.am perhaps have a new macro named lsrc to be
consistent with the present src and fsrc?
Sounds good, I changed that too.

Suggestion:  instead of always using the same big expression
+#if defined(__GNUC__) && (!defined(__STRICT_ANSI__) ||
defined(__cplusplus) || \
+     __STDC_VERSION__ >= 199901L) && (DBL_MANT_DIG == LDBL_MANT_DIG &&
\
+     LDBL_MIN_EXP == DBL_MIN_EXP && LDBL_MAX_EXP == DBL_MAX_EXP)

define a shorter one that gets put into math.h. For example:

#if (!defined(__STRICT_ANSI__) || __STDC_VERSION__ > 199901L || \
defined(__cplusplus))  &&  defined(LDBL_MANT_DIG)  &&  \
	(DBL_MANT_DIG == LDBL_MANT_DIG && \
	LDBL_MIN_EXP == DBL_MIN_EXP && LDBL_MAX_EXP == DBL_MAX_EXP)
  #define _LDBL_EQ_DBL
#endif
[Notice that I added a check for LDBL_MANT_DIG being defined, as it
is possible for long double to not exist if it's a C89 compiler but
without STRICT_ANSI having been selected.  (This is my 2nd suggestion.)
Since we've assumed the presence of float.h, checking any of the LDBL
defines is the same as a configure check for AC_TYPE_LONG_DOUBLE.
No need for configure when float.h can be assumed.]

Then, in all of the libm files (and a few places in math.h, itself):
#include <math.h>
#if defined(_LBDL_EQ_DBL)
...
#endif

The new patch defines _LBDL_EQ_DBL within _ansi.h because this header file is included from both stdlib.h and math.h. Let me know if there is a better place to put it.


This is very similar to using AC_TYPE_LONG_DOUBLE_WIDER from one
place, but is doing it via float.h instead of configure.
In addition to being easier to read in the source files, it permits
an easy modification of the if for all of the source in 1 place
instead of needing to edit it in many, should the need ever arise.
(An interesting future possibility is if a system used, for example,
128 bits for double and long double.  The present routines hard code
64 or 32 bits for double.  So if at that time there were 128-bit LD
routines, _LDBL_EQ_DBL would not be defined, but _DBL_EQ_LDBL could
be, which would then map the double routines to the long double.  And
this will probably happen at about the same time that the US government
actually returns to a balanced budget.)

I've been planning a LDBL_EQ_DBL define for the real long double
routines
that I'm working on, but have it in a math library local include.
"Promoting" it to math.h probably makes sense.

A minor variation of the above is to also define something that says
long double ought to be used, where a potential user-configured choice
to not use long double even if it could be is also demonstrated:
#if (!defined(__STRICT_ANSI__) || __STDC_VERSION__ > 199901L || \
defined(__cplusplus))  &&  defined(LDBL_MANT_DIG)  &&  \
	!defined(SKIP_LDBL)
  #define _USE_LDBL
#endif

Then, in all of the libm files (and a few places in math.h, itself):
#include <math.h>
#if defined(_USE_LDBL) && defined(_LBDL_EQ_DBL)
...
#endif
Or, down the road:
#if defined(_USE_LDBL)
#if !defined(_LDBL_EQ_DBL)
real function
# else
wrapper
#endif
#endif
_USE_LDBL probably does not make sense in the source files, as would
make more sense to leave the LDBL source out of the makefiles. But it
could make sense in header files.

Why would anyone with a platform where there's no difference between double and long double prefer the long double routine?


Craig
Thanks
Ken



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]