Porting Questions
David A. Greene
greened@eecs.umich.edu
Thu Jun 28 16:04:00 GMT 2001
Gabriel Dos Reis wrote:
> | Ok, I think I'm following you here. What you're saying
> | is to esentially put compiler runtime changes into libstdc++.
> | Really, all this does is build a runtime support library
> | for the compiler, which IMHO should stay with the compiler.
> | I could easily implement __builtin_* for our compiler as
> | a special runtime library, no sweat. But this doesn't help
> | all the other compilers out there. Your solution _does_
> | help all the other compilers but at the expense of being
> | overly complicated, IMHO.
>
> Overly complicated ?
In the sense that it adds code the libstdc++ that IMHO doesn't
really belong there. But it exists already, so maybe it's not
too bad to add it.
> 1) Using autotools, you can list the missing functions -- you can even
> reuse c++config.h.
After looking through libmath today, I see a lot of functions
already in libmath/stubs.c. Since config.h already provides
_GLIBCPP_HAVE___BUILTIN_*. I've started defining __builtin_*
if that macro is not defined. At least for the math functions.
Other stuff like __builtin_alloca will go somewhere else
(suggestions?). __builtin_alloca may get a bit tricky because
it may need to be inlined (i.e. really be "built in").
> 2) Except from __builtin_alloca, all __builtin_xxx do
> have standard forms (from the C library) or can readily be implemented
> in terms of C standard functions.
Right. I didn't mean complicated as in "hard." I meant it
as in "unnecessary maintenance."
> You can use #define if that helps solve your problem, but I'm not
> willing to play more CPP hackery games in V3 headers. The point is
> that, somehow you have to provide some homegrown definitions for some
> missing symbols to accomodate some targets, so you'll have to do what
> I'm saying in one or another form.
Sure, I can understand your viewpoint. I've started putting
some stuff into libmath/stubs.c. If that's not the right place,
say so now or forever hold your peace. :)
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. 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?
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.
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.
Thanks!
-Dave
More information about the Libstdc++
mailing list