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'


>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

>>>>> "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:

OK, it's already been created.  But I still don't like it.

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

Agreed.

> I want to make it up to the V3 people to wire the latter to the
> former, as they've already done.

This is where I disagree.  I don't think the V3 people should have to worry
about this stuff.  For one thing, it interferes with the goal of writing a
portable library.

> To be clear, I'm not proposing that the library open-code `fabs' in
> the optimal assembly code or anything like that; I just want to make
> the only builtins we declare in C++ be those that start with
> `__builtin'.

Jason> I like Joseph's idea; I think it would make sense to
Jason> generalize nothrow_libfn_p to handle attributes other than
Jason> nothrow-ness.

> I didn't connect the part after the `;' with the part before, but
> that's OK. :-)

Currently, when we declare a function, we look to see if it's a known
nothrow C library function.  I'm suggesting that we can also look for a
builtin handler, or noreturn-ness, or whatever other magic we want to know
about a function, and set them up in the same code.

> I agree that in C Joseph's idea (lazily create the non __builtin
> builtins as needed) makes sense.  But, in C++, I don't think we need
> bother.

I think my way is simpler, actually.  It certainly keeps the information
more localized.

Jason


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