This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Porting Questions
"David A. Greene" <greened@eecs.umich.edu> writes:
| Other stuff like __builtin_alloca will go somewhere else
Right. We used __builtin_alloca becuase we can't properly handle
extensions in GCC (C99 VLAs would have been used).
| Sure, I can understand your viewpoint. I've started putting
| some stuff into libmath/stubs.c.
That is OK, as far as it is concerned with "C" functions.
| Once quesion about long double:
|
| I see in include/c_std/bits/std_cmath.h (the C headers I'm
| using in my build -- don't yet know if it's the same for the
| others) that, for example, we have this code:
|
| #if _GLIBCPP_HAVE_ACOSL
| inline long double
| acos(long double __x) { return ::acosl(__x); }
| #else
| inline long double
| acos(long double __x) { return ::acos(static_cast<double>(__x)); }
| #endif
|
| So the argument gets converted to a less-expressive type.
Yes, this is a leftover of a period where we wanted to have the
necessary symbols there, and later provide the right semantics. It is
just that I didn't have the time to implement full trigonometric
functions where the C library fails to define them.
| Is
| this the template I should follow for things like abs(long double)
| that currently assume the existence of a builtin long double form
| or should I provide a builtin form, potentially (probably)
| doing the same conversion internally?
For easy things like abs(long double), it is better to provide the
builtin forms definition with the right accuracy.
| Along the same lines, I see macro checks for acosf but no similar
| checks for any of the __builtin_* functions. This seems somewhat
| irregular. I don't mind implementing __builtin_* in stubs.c,
| but then shouldn't acosf be provided for completeness? I'm just
| curious on this point. It seems sometimes #ifdef's are used
| and sometimes functions are just expected to be there.
Well, you have a point here. Ages ago, when we started implementing
the math stuff, we're playing #ifdef games with various symbols.
Latter I find it really less painful to rely on GCC semantics :
Unconditionally use the __builtin_xxx -- if GCC can't inline it
then it will make a regular library call to the "C" function xxx.
Then recently, I added the stubs.c file to support AIX where numerous
symbols were missing.
The irregularity you're seeing has two sources:
1) GCC doesn't have builtin support for the trigonometric inverse
functions;
2) I didn't have the time to finish converting all the
header to __builtin_xxx form.
That is th story -- the move is toward the __builtin_xxx form.
I'll made request for a compiler support for more math functions.
| BTW, the install instructions aren't really clear about what it
| means for choose c_std, c_shadow, etc. for the C headers. I'm
| using c_std because it's the default. Could someone explain
| and/or put an explanation into the install instructions? Same
| deal for --enable-cstdio.
Hmm, I'll leave that to Phil, our expert in installation. But, for
the time being you can safely forget about c_shadow.
-- Gaby