On 17/11/2015 13:58, Joseph Myers wrote: >> > GCC's -fwrapv option does not affect code generation for shifts >> > because currently GCC does not rely on the fact that certain >> > signed shifts trigger undefined behavior. However, the definition >> > of signed arithmetic overflow does extend to shifts; it is only >> > code generation that is limited to addition, subtraction and >> > multiplication. > It is part of the GNU C language, independent of -fwrapv, that shifts > where the shift amount is in the range [0, width - 1] are fully defined > (although ubsan will still sanitize those not defined in ISO C)
-fwrapv should probably disable those checks, just like it disables e.g. "signed integer overflow: 1 + 2147483647 cannot be represented in type 'int'". > - they are > considered to be defined in terms of bits, not integers, so overflow is > not a meaningful concept for them. Can you suggest a wording for "if the GNU C language definition changes [which, no matter how unlikely, is explicitly not ruled out by the manual] -fwrapv will be extended to signed shifts, and shifts of negative numbers would return A*2^B whenever the result fits in the type"? Paolo > -fwrapv *should* however affect division and modulo -1, although it > doesn't at present (see bug 30484).
