[cfe-dev] Proposed change to __builtin_overload
Chris Lattner
clattner at apple.com
Mon Feb 9 00:55:09 PST 2009
I've been pondering on tgmath.h, but it is more evil than I thought.
As such, I'd like to extend __builtin_overload like this:
http://clang.llvm.org/docs/LanguageExtensions.html#__builtin_overload
The basic problem is that tgmath doesn't follow standard arithmetic
promotion rules. For example fmax(int, float) is supposed to call the
double version of fmax, not the float version as normal promotion
rules would specify.
Because I couldn't find a non-evil approach to handling this (e.g.
with builtin_classify_type like GCC does) I just decided to allow a
fixed set of programmable promotion rules. This way, we can support
any craziness in altivec.h, support the standard promotion rules, and
support tgmath.h all in one framework.
I noticed this in altivec.h, which I found pretty amusing/scary:
/* Predicates.
For C++, we use templates in order to allow non-parenthesized
arguments.
For C, instead, we use macros since non-parenthesized arguments were
not allowed even in older GCC implementation of AltiVec. */
/* Be very liberal in the pairs we accept. Mistakes such as passing
a `vector char' and `vector short' will be caught by the middle-end,
while any attempt to detect them here would produce hard to
understand
error messages involving the implementation details of AltiVec. */
I think the first argument to __builtin_overload will completely fix
the ugly hack they are using here (rejecting bugs in codegen instead
of in sema).
If this isn't completely revolting to people, I'll implement it in the
next few days.
Oh yeah, we also now have a place to document our language extensions,
woo.
-Chris
More information about the cfe-dev
mailing list