5 ms·

> Overflow in the positive direction shall wrap around This appears to be defining signed integer overflow semantics, which prevents the compiler from doing ce

> Overflow in the positive direction shall wrap around This appears to be defining signed integer overflow semantics, which prevents the compiler from doing certain basic optimizations, for example, that (x*2)/2 == x. Is that part of this? Has anyone measured the perf cost on a real program?

userbinator 8y ago
It prevents risky optimisations; this now requires the compiler to prove that such optimisations won't change the semantics of the code, e.g. in your case by essentially proving that the high 2 bits of x (only 1 in the unsigned case, due to sign-extension) will never be set. ...and it could be argued that if the compiler couldn't prove that was true, then it just helped you find a possible overflow bug in the code. If you actually wanted the compiler to unconditionally assume (x*2)/2==x and optimise accordingly, then you'd have to tell it such; e.g. MSVC has the __analysis_assume() feature.
- caf 8y ago
  However it also prevents "abort on overflow" implementations from being conforming, which look like a much better way of finding actual overflow bugs in the code.
  - DoofusOfDeath 8y ago
    That's a question of static vs. dynamic analysis for bug detection. Which one(s) is/are most useful depends on the user's needs.
    - simias 8y ago
      Static analysis was always possible, dynamic isn't if you want to remain standard-compliant and overflow is defined. That being said I think it's a rather weak justification for making overflow UB, after all if you want to trap on overflows wouldn't want to catch unsigned overflow as well?
  - mort96 8y ago
    Do such implementations currntly only abort on signed overflow and not on unsigned overflow? Aborting on unsigned overflow is currently not conforming, is it?
    - scatters 8y ago
      It is not conforming, which is why `-fsanitize=unsigned-integer-overflow` is not enabled by default by ubsan. However it is available if you want to try it.
- ridiculous_fish 8y ago
  The compiler could help you more by emitting trapping arithmetic. Code that triggered signed overflow will probably not be "fixed" by this change alone. For example consider the classic binary search blunder: `mid = (low + high)/2`. Defining signed overflow may avoid the UB in computing mid, but now we have a surprise negative value and it's easy to guess what happens next. It will be fun to see the trophies from this: perf regressions, bugs exposed, bugs fixed.
  - scatters 8y ago
    This is already an option: `-ftrapv` or `-fsanitize=signed-integer-overflow`. I find it amusing (and somewhat frustrating) that people who complain about risks from optimizations typically exhibit a lack of awareness of the tools that compilers already provide to diagnose related bugs.
cornholio 8y ago
> for example, that (x&~1*2)/2 == x Fixed that for you.
- caf 8y ago
  No? If x is 3, then (x * 2) / 2 is also equal to 3 (as per the GP) but (x & ~1 * 2) / 2 is equal to 0. (If you meant ((x & ~1) * 2) / 2, then that is equal to 2).
  - cornholio 8y ago
    You are of course correct. Not only have I mistook precedence, but I confused the lower bit with the upper one where overflow occurs. So the compiler optimizable fix is something like: ((x & INT_MAX) * 2) / 2 = x
    - caf 8y ago
      ((x & (INT_MAX / 2)) * 2) / 2 ?
      - cornholio 8y ago
        My version works up to x = INT_MAX and your version still fails for negative ints, so I don't see the benefit of restricting the range. Getting closer :)
sanxiyn 8y ago
The link is revision 0. Revision 1 reverted defining signed integer overflow. In revision 1, signed integer overflow is still undefined, precisely for this reason.
deathanatos 8y ago
For some examples of the types of optimizations enabled by allowing overflow to be undefined: https://kristerw.blogspot.com/2016/02/how-undefined-signed-overflow-enables.html https://kristerw.blogspot.com/2016/02/how-undefined-signed-o...

userbinator 8y ago

It prevents risky optimisations; this now requires the compiler to prove that such optimisations won't change the semantics of the code, e.g. in your case by essentially proving that the high 2 bits of x (only 1 in the unsigned case, due to sign-extension) will never be set. ...and it could be argued that if the compiler couldn't prove that was true, then it just helped you find a possible overflow bug in the code. If you actually wanted the compiler to unconditionally assume (x*2)/2==x and optimise accordingly, then you'd have to tell it such; e.g. MSVC has the __analysis_assume() feature.

caf 8y ago
However it also prevents "abort on overflow" implementations from being conforming, which look like a much better way of finding actual overflow bugs in the code.
- DoofusOfDeath 8y ago
  That's a question of static vs. dynamic analysis for bug detection. Which one(s) is/are most useful depends on the user's needs.
  - simias 8y ago
    Static analysis was always possible, dynamic isn't if you want to remain standard-compliant and overflow is defined. That being said I think it's a rather weak justification for making overflow UB, after all if you want to trap on overflows wouldn't want to catch unsigned overflow as well?
- mort96 8y ago
  Do such implementations currntly only abort on signed overflow and not on unsigned overflow? Aborting on unsigned overflow is currently not conforming, is it?
  - scatters 8y ago
    It is not conforming, which is why `-fsanitize=unsigned-integer-overflow` is not enabled by default by ubsan. However it is available if you want to try it.
ridiculous_fish 8y ago
The compiler could help you more by emitting trapping arithmetic. Code that triggered signed overflow will probably not be "fixed" by this change alone. For example consider the classic binary search blunder: `mid = (low + high)/2`. Defining signed overflow may avoid the UB in computing mid, but now we have a surprise negative value and it's easy to guess what happens next. It will be fun to see the trophies from this: perf regressions, bugs exposed, bugs fixed.
- scatters 8y ago
  This is already an option: `-ftrapv` or `-fsanitize=signed-integer-overflow`. I find it amusing (and somewhat frustrating) that people who complain about risks from optimizations typically exhibit a lack of awareness of the tools that compilers already provide to diagnose related bugs.

cornholio 8y ago

> for example, that (x&~1*2)/2 == x Fixed that for you.

caf 8y ago
No? If x is 3, then (x * 2) / 2 is also equal to 3 (as per the GP) but (x & ~1 * 2) / 2 is equal to 0. (If you meant ((x & ~1) * 2) / 2, then that is equal to 2).
- cornholio 8y ago
  You are of course correct. Not only have I mistook precedence, but I confused the lower bit with the upper one where overflow occurs. So the compiler optimizable fix is something like: ((x & INT_MAX) * 2) / 2 = x
  - caf 8y ago
    ((x & (INT_MAX / 2)) * 2) / 2 ?
    - cornholio 8y ago
      My version works up to x = INT_MAX and your version still fails for negative ints, so I don't see the benefit of restricting the range. Getting closer :)

sanxiyn 8y ago

The link is revision 0. Revision 1 reverted defining signed integer overflow. In revision 1, signed integer overflow is still undefined, precisely for this reason.

deathanatos 8y ago

For some examples of the types of optimizations enabled by allowing overflow to be undefined: https://kristerw.blogspot.com/2016/02/how-undefined-signed-overflow-enables.html https://kristerw.blogspot.com/2016/02/how-undefined-signed-o...