There have been numerous issues in the past with respect to the undefinedness of signed overflow in our IL, with the non-semantics of sizetype and friends and with the pessimization of using unsigned arithmetic vs. signed arithmetic in loop optimizations.
The goal of the no-undefined-overflow branch is to address all these problems by tackling the single worst problem, imposing There shall be no construct in the GIMPLE IL that invokes undefined behavior. Thus, from now on integer overflow is defined and will wrap with the usual twos-complement semantics. Thus, for the middle-end -fwrapv is always in effect. This extends to pointer overflow. To support languages that have undefined semantics on overflowing operations the middle-end gets new unary and binary operators that implicitly encode value-range information about their operands noting that the operation does not overflow. These does-not-overflow operators transform the undefined behavior into a valid assumption and thus make the GIMPLE IL fully defined. Thus it is now up to the frontend(s) and value-range analysis to figure out if operations overflow and accordingly change the IL to retain optimizations that were possible before. As a start there will be no-overflow variants of NEGATE_EXPR, PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR. The sizetypes will simply be operated on in no-overflow variants by default (by size_binop and friends). Naming suggestions welcome, at the moment I consider NEGATEV_EXPR (thus appending V to the first part). Richard.
