On 17/11/2015 16:27, Joseph Myers wrote: > > 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"? > > I don't think we can usefully say how a hypothetical change in one area > would or would not affect a particular option.
I agree. That is why I phrased my original patch in the other way, assuming that overflow _can_ be defined for signed left shifts but it is not treated as undefined. My definition of overflow for signed left shifts would be shifting a 1 into or out of the sign bit. However, I understood that you don't want to define overflow of signed left shifts. The reason why I am proposing this patch is that the current documentation has a sort of catch-22: * it doesn't promise that GCC will never rely on undefined behavior rules for signed left shifts * it says that -fwrapv affects add/sub/mult This means that GCC has no future-proof option for projects that wish to rely on definedness of signed left shifts. In fact, as you mentioned, ubsan _already_ provides a case where GCC does not treat left shift as an operation on the bit representation. This makes it even more important to define such an option _now_ and to make ubsan respect it (for which I've also sent an RFC patch earlier today). Paolo
