[cfe-dev] Proposed change to __builtin_overload

[Howard Hinnant]

On Feb 9, 2009, at 3:55 AM, Chris Lattner wrote:

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

Looks reasonable but I see a bug:

The choices "tgmath" and "tgmath1" are too limiting.  I suspect that  
you will ultimately need a way of specifying any combination of the  
arguments are "generic".  "tgmath" is interpreted as "all parameters  
are generic" and "tgmath1" as "the first parameter is generic."   
There's no telling what the C committee will throw at you next year.   
And indeed, they've already bitten you with remquo:

    double remquo(double x, double y, int *quo);

Both x and y are generic, but not quo.

The C++ <cmath> has to implement this same logic, but gets to use C++  
to do it. :-)  If it is helpful, see the cayuga <cmath> and  
<type_traits> for an example C++ implementation, at least for the non- 
complex parts.  I'm not suggesting that clang's <tgmath.h> be  
implemented in C++.  Only that seeing a C++ implementation may spark  
an idea for a more flexible __builtin_overload.

Or at the very least, you need "tgmath2". :-)

-Howard