Re: long double (was "strtold?")

[Ken Werner <ken at linux dot vnet dot ibm dot com>]

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. : )

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.

Regards
Ken