RE: long double (was "strtold?")

["Howland Craig D (Craig)" <howland at LGSInnovations dot com>]

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.)
 
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).
 
Should libm/common/Makefile.am perhaps have a new macro named lsrc to be
consistent with the present src and fsrc?
 
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
 
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.
 
Craig
 

-----Original Message-----
From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
On Behalf Of Ken Werner
Sent: Wednesday, April 01, 2009 5:02 PM
To: newlib@sourceware.org; Jeff Johnston
Subject: Re: long double (was "strtold?")

On Monday 30 March 2009 22:42:17 Jeff Johnston wrote:
> > All in all it looks like implementing small wrapper functions that
just
> > call their counterparts seems to be the way to go - as you
suggested. : )
>
> Ok, great.  It should not be a code-size issue as you earlier
> mentioned.  Any application that calls
> a C library function has to expect something gets linked in.  A small
> stub that calls another function
> is hardly surprising.

The attached patch adds these wrapper functions. I initially intended to
use 
the AC_TYPE_LONG_DOUBLE_WIDER macro in newlib/libm/configure.in but
there is no 
AC_CONFIG_HEADERS and I guess there is a reason for that. Therefore I
guarded 
the code itself. Maybe there is a better solution - just let me know. :
)

> > For the SPU target I'd like to use GCC aliasing to save code size
and
> > don't pay the penalty of an extra function call. I'll post a patch
as
> > soon as I find some time.
>
> If you do an SPU-only solution, a preferred way would be to add a
> machine/math.h extension to math.h and then have a
> libc/spu/machine/math.h file.  In libc/include/machine have a math.h
> that defaults to empty for everyone else.

I did so and aliased the long double functions within the existent .c
files of 
the SPUs math implementation since they have to be in the same
translation 
unit. Unfortunately the wrappers that have been added for the common
code are 
visible on the SPU target too which result in duplicate definitions. It
looks 
like the overlaying of target specific math routines is made by file
names. 
Adding empty files seems not be an option. Is there a nice way to do it?

> -- Jeff J.
Regards
Ken