This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Porting Questions

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:

inline long double
acos(long double __x) { return ::acosl(__x); }
inline long double
acos(long double __x) { return ::acos(static_cast<double>(__x)); }

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]