Re: long double (was "strtold?")

[Jeff Johnston <jjohnstn at redhat dot com>]

Ken Werner wrote:
> On Monday 30 March 2009 11:44:37 Ken Werner wrote:
>   
> > > If the platform normally prepends an underscore to a C function, you are
> > > not going to call
> > > the correct C math functions and the linker is going to fail.  Feel free
> > > to correct me if I have misinterpreted
> > > this.
> > >       
> > I see your point. How does the prepend mechanism work on those platforms? I
> > guess calling the correct function could be achived by conditionally
> > prepend the underscore using macro substitution.
> >     
>
> The GCC defines __USER_LABEL_PREFIX that could be handy.
>
>   
> > > Thus, I would like to see this implemented as it is done for
> > > DOUBLE_IS32BITS.  The functions
> > > are declared and implemented as calls to the double versions with casts.
> > >       
> > Implementing these stubs would work but it would increase the code size
> > too. The GCCs aliasing mechanism might be an alternative. In that case the
> > mapping needs to be done in the translation unit of the referred symbol.
> >
> > The mechanism described in GCCs info page 5.36 "Controlling Names Used in
> > Assembler Code" allows the users code to link against the double
> > counterparts. This could help architectures where the long double is going
> > to change in the future. However, I'm not sure if this approach is
> > compliant with the C99 standard.
> >     
>
> We found an actual problem using the  __asm__ approach. The GCC build fails 
> for libgfortran. The configure script checks whether the use of the log10l 
> function fails to link and sets a corresponding flag called HAVE_LOG10L. The 
> c99_functions.c of libgfortran includes <math.h> which maps log10l to log10 if 
> my patch is applied. libgfortrans log10l function itself calls the log10 and 
> you're stuck in an infinite loop. Such things may happen to other code too. So, 
> using the __asm__ mapping method seems not to be the best idea if you can't 
> touch the compiler and/or the source code.
>
> Mapping the long double functions using GCCs __attribute__ (alias) mechanism 
> also has its flaws. Beside from the fact that the aliasing need to be done in 
> the same translation unit and is only available on GCC (and compatible) it 
> assumes the calling convention for long double arguments is the same as for 
> double args. Most likely this is true but it's not guaranteed.
>
> 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.
> 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.

-- Jeff J.
> Regards
> Ken
>