[cfe-dev] Proposed change to __builtin_overload

[Howard Hinnant]

On Feb 9, 2009, at 9:56 AM, Howard Hinnant wrote:

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

One possible variation:

Change PromotionRuleStr to the form:

     "PromotionRuleArg1, PromotionRuleArg2, ..."

remquo example:

    "tgmath, tgmath, none"

Then you can drop the NumArgs argument because you already have it by  
counting commas in the PromotionRuleStr.

-Howard