[EMAIL PROTECTED] wrote: > Currently, the prototype for __builtin_expect is > > long __builtin_expect (long expression, long constant); > > Extending it to functions would change it to > > T __builtin_expect (T expression, T expected);
Yes, it really makes more sense for __builtin_expect to be polymorphic in this way anyhow. I consider it a design wart that it's defined in terms of "long". (For example, this means you can't use it for "long long"!) > Rather than the above definition, we could choose not to inspect the > context and just say: > * T is the type of 'expression' > * 'expected' is allowed to be a non-constant > > In this case I think there would only be compatibility issues with > unusual uses of __builtin_expect, for example, if it was being used in a > function argument and its type effected overload resolution. I think this is the abstractly right approach. However, you're right that there are backwards-compatibility issues. Another issue is that on platforms where "long" and "int" do not have the same width, something like: sizeof(__builtin_expect(1, 1)) will change its value. And, the current prototype is documented in the manual. What do people think? Do we have the leeway to change this? Or should we add __builtin_expect2? Or add an -fno-polymorphic-builtin-expect? Or...? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
