Porting Questions

[David A. Greene]

Gabriel Dos Reis wrote:

> "David A. Greene" <greened@eecs.umich.edu> writes:
> | 
> | - There are many places where gcc's __builtin_* functions
> | are called.  Obviously, we don't have these.  Right now

> | functions and #define be appropriate?  For example, test
> | for __builting_alloca and #define ALLOCA_FUNCTION to
> | alloca or __builtin_alloca as appropriate.
> 
> Basically we build a config header file at configure time pretty much
> like c++config.h. Then your create a file, call it your-stubs.cc
> (#including you header config file) where you define the 
> missing functions.  Then you link it to the library.
> You don't need to play macro hackery games.  If your compiler happens
> to implement the missing __builtin_xxx then the only thing you need is
> to remove your-stubs.cc.

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.

Is this really what people want me to do?  If so, I'll do
it, but it seems uglier than a #define to me. It does
solve the problem of fabs(long double), of course.

> | - I have the same problem with NULL.  Our compiler doesn't
> | like the assignment of (void *)(0) to non-void pointers.
> | I could test for this as well and #define NULL_POINTER
> | to the appropriate thing.  Is there a better way.
> 
> Just redefine it -- anyway, (void *)0 is not acceptable for C++.

Right.  As I mentioned it comes from an old, old glibc.
I'll hack the C library for this one as this is not
a libstdc++ issue.

> | How does this build work under g++ (i.e. how does it get
> | all the instantiations right when it can't see all the
> | code?)
> 
> This depends on how friendly is the host linker. A thorny issue,
> requiring generally non contorsious solutions.

Erm...It works for gcc, somehow.  gcc obviously has some
way of seeing template specialization code when that code
is not visible from files containing explicit template
instantiations.  How does this work?  It seems like magic
to me.

Our compiler must see all the template code at the point
of template instantiation.  This is not possible with
the current locales setup.  I'll need to fix it.  I'd
like to fix it so as to impact the least amount of code
and people as possible.  I suppose in the end I'll just
have to Make It Work and submit the patch for review.

-Dave