This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: long double (was "strtold?")
On Friday 27 March 2009 19:47:59 Jeff Johnston wrote:
> My apologies for the delay in reviewing this. According to the gcc info:
>
> ***************************************************************************
>***** You can specify the name to be used in the assembler code for a C
> function or variable by writing the `asm' (or `__asm__') keyword after
> the declarator as follows:
>
> int foo asm ("myfoo") = 2;
>
> This specifies that the name to be used for the variable `foo' in the
> assembler code should be `myfoo' rather than the usual `_foo'.
>
> On systems where an underscore is normally prepended to the name of a C
> function or variable, this feature allows you to define names for the
> linker that do not start with an underscore.
> ***************************************************************************
>*****
>
> 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.
> 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.
> -- Jeff J.
Regards
Ken