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:

> "David A. Greene" <> 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 wasn't questioning the USE of alloca, but rather
asking where non-math stuff in general should go.
__builtin_alloca was a bad example due to its funny semantics.
IIRC, this is the only non-math function that is currently
giving me problems.  But in general it would be good to know
where to various support functions.

> | 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. 

Great, I'll continue in this fashion, then.

> | 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.

I'm not criticizing the choice.  Rather, I'm asking if someone
is going to holler if I do the same thing for some of the
__builtin_* and other functions.  I really don't have the
time to implement proper semantics and I don't need them
for my work.  Since I'm currently the only one (that I'm
aware of) using a non-gcc compiled libstdc++, I don't think it
will be a problem.

> | 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.

Hrm...That's a little more work than I'm willing to do right
now.  We don't support long double in our compiler at the
moment and we have no presssing need to add it.  Implementing
it would just be a waste of time for us.  Of course, things
like abs should be easy enough to do without full compiler
support, though it will be less than optimal for some
functions.  I'll implement the proper semantics at my
discretion, I think.  Certainly not right away.

> | curious on this point. It seems sometimes #ifdef's are used
> | and sometimes functions are just expected to be there.
> 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. 

Ok, no problem.  I figured it was an inconsistency due to
legacy code.  Since I only need __builtin_* right now,
I'll just implement those and leave the other stuff alone.

> | 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.

Ok.  My changes are going into c_std ONLY at the moment.
It should be easy enough to port them over to the
other headers as necessary, though as I said I've not
looked at them.

Thanks for your comments, Gabriel.  They have brought
higher quality to my work. :)


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