pub struct Wrapping {
pub signed: bool,
pub pointer: bool,
pub trap: bool,
}Expand description
What overflows rather than being undefined, which is -fwrapv and its relatives.
Every licence the walk grants the optimizer about overflow is one flag on one instruction, and withdrawing a licence is not setting it. So this is read where the flags are chosen and nowhere else, and a unit built with either of these is a unit whose IR carries less rather than a unit the passes are told something extra about. That is also what makes it correct across link time optimization: a body from a unit that wraps and a body from one that does not keep their own answers when they end up in the same module.
-ftrapv is the exception and is the reason this is not simply two flags. It is the other
answer to the question -fwrapv answers, and it is the only one of the three that asks for
something to be generated rather than for something to be left out.
Fields§
§signed: boolWhether signed arithmetic wraps, from -fwrapv. Set, and an add, a subtract, a multiply, a
shift and a negation in a signed type stop saying they do not wrap.
pointer: boolWhether pointer arithmetic wraps, from -fwrapv-pointer. Set, and the multiply that turns
an index into a number of bytes stops saying so.
That multiply is the whole of it here, because the addition itself never claimed anything: a
ptradd carries no flags in this IR and no pass reads one off it.
trap: boolWhether a signed overflow stops the program, from -ftrapv. Set, and an add, a subtract, a
multiply and a negation in a signed type become calls to the routine in the runtime that
does the arithmetic and checks it.
Never set at the same time as Wrapping::signed, because a program cannot both wrap and
stop. The driver is what keeps that true.