On 10/11/15 12:06, Richard Earnshaw wrote: > On 10/11/15 10:44, David Brown wrote: >> But consider if integer overflow were made "unspecified" rather than >> "undefined" - i.e., it were guaranteed to return a valid integer, but >> you know nothing about /which/ integer it is. For efficiency, that >> would require that the hardware does not have enforced traps on >> overflow. But the compiler is still able to optimise "x * 3 / 6" to "x >> / 2", and still able to assume that "x + 1 > x". But given "x = 1290; >> foo(); y = x * x * x;" it is no longer able to eliminate the call to "foo". >> > > I /think/ you've just said that x86 can no-longer use its divide > instruction. That instruction faults if you have n/0 or INT_MIN/-1. > That's why it's good that there are lots of people thinking together on these specifications, and not just one person! Or perhaps we should all switch to using ARM chips... Annex L allows traps or exceptions as part of "bounded undefined behaviour". But if an instruction can trap, then it is more difficult to move around - a trap is (presumably) observable behaviour, whereas something that produces an unspecified but valid result is not observable and can be re-arranged more easily.
