On 06/10/2016 01:08 PM, Jakub Jelinek wrote:
Hi!
As mentioned in PR71479, for __builtin_*_overflow we right now require
the last argument to be pointer to INTEGER_TYPE, not INTEGRAL_TYPE_P,
but for __builtin_*_overflow_p we were using INTEGRAL_TYPE_P.
For _Bool/bool, I'd think we could make it well defined if we wanted
(check if the infinite precision result is 0 or 1), but it is hardly useful
and as can be seen, right now we don't implement that (for bool we actually
check if the result fits into unsigned 8 bit integer
I agree that computing the bool result isn't terribly useful when
the type is known, but allowing it could be handy in generic code
(macros, C _Generic, and C++ templates). Rejecting it, OTOH, means
that users will have to work a little harder to avoid an error in
generic contexts. Unless there is some potential problem that I'm
not thinking of I would suggest to accept bool.
IMO, the right semantics for bool are to match what the standards
specify (i.e., no overflow, and the result is a logical OR of the
operands).
Continuing to reject enumerated and complex integer types makes
sense to me.
Martin
