[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