On Fri, Jun 10, 2016 at 01:28:55PM -0600, Martin Sebor wrote:
> 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).
??? It is far from that.
The documentation says that say for __builtin_add_overflow (x, y, &z), you
compute
infinite precision signed result of x + y, cast the result to __typeof (z),
extend again to infinite precision signed result and compare to the value
before casting. So, if z is bool/_Bool, then this means
signed_intNNN_t t = (signed_intNNN_t) x + (signed_intNNN_t) y;
z = (__typeof (z)) t;
ovf = (signed_intNNN_t) z != t;
But, unlike normal signed or unsigned integral types or char, cast to
bool/_Bool is special, it is actually a comparison != 0.
So, I'd say if we want to support arith overflow to bool/_Bool, it should be
above with:
signed_intNNN_t t = (signed_intNNN_t) x + (signed_intNNN_t) y;
z = t != 0;
ovf = (signed_intNNN_t) z != t;
so in the end, if we'd use
movb x, r
addb y, r
seto ovf
to compute whether the result overflowed 8-bits, we'd need to
or in (r & 254) != 0 into the ovf and then or in ovf into r.
That means changes everywhere where we handle the overflow builtins. :(
Jakub
