This is the mail archive of the libstdc++@gcc.gnu.org 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


"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


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