This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


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

Re: Builtins in `std'


Jakub Jelinek <jakub@redhat.com> writes:

| On Wed, May 23, 2001 at 08:45:23AM -0700, Mark Mitchell wrote:
| > >>>>> "Jason" == Jason Merrill <jason_merrill@redhat.com> writes:
| > 
| >     Jason> I agree that the current builtin handling is unfortunate.
| >     Jason> But I'm not sure that moving it into the library is the
| >     Jason> right path, as it creates yet another version lock between
| >     Jason> library and compiler.
| > 
| > I don't understand this point.
| > 
| > The library already uses `__builtin_*' all over the place:
| > 
| >   namespaces std {
| >   #if _GLIBCPP_HAVE___BUILTIN_FABS
| >     inline double 
| >     fabs(double __x) { return __builtin_fabs(__x); }
| >   #else
| >     extern "C" double fabs(double __x);
| >   #endif
| >   }
| > 
| > I want this code to still work, because I want us to still declare
| > `::__builtin_fabs' which is safely out of the user namespace.  But, I
| > want us to not declare `std::fabs' which is in the library namespace.
| > I want to make it up to the V3 people to wire the latter to the
| > former, as they've already done.
| 
| This way you have tight lock between g++ version and libstdc++, because if
| g++ 3.1.5 decides to optimize std::foo then it has to wait until libstdc++
| changes it headers.

libstdc++ is already locked with g++.  Actually, I don't find the
__builtin_foo thing to be a big lock.  I think Mark's proposal is
sound and robust.

-- Gaby


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