5 ms·

More than slightly convoluted. The obvious intention is that the compiler ignores overflow and lets the processor architecture make the decision. Assuming that

More than slightly convoluted. The obvious intention is that the compiler ignores overflow and lets the processor architecture make the decision. Assuming that overflow doesn't happen is assuming something false. There's no excuse for that and it doesn't "optimize" anything.

aw1621107 5y ago
> The obvious intention is that the compiler ignores overflow and lets the processor architecture make the decision. If that were the case, wouldn't signed overflow be implementation-defined or unspecified behavior, instead of undefined behavior? > Assuming that overflow doesn't happen is assuming something false. It's "false" in the same way that assuming two restrict pointers don't alias is "false". It may not be universally true for every single program and/or execution, but the compiler is explicitly allowed to disregard cases where the assumption may not hold (i.e., the compiler is allowed to "ignor[e] the situation completely"). And again, the compiler is allowed to make this assumption because undefined behavior has no defined semantics. If the compiler assumes that no undefined behavior occurs, and undefined behavior does occur, whatever happens at that point is still conforming, since the Standard says that it imposes no requirements on said program. > it doesn't "optimize" anything. ...But it does allow for optimizations? For example, assuming signed overflow can allow the compiler to unroll/vectorize loops when the loop index is not the size of a machine word [0]. Godbolt example at [1]. [0]: https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759de5a7 https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759... [1]: https://godbolt.org/z/sP6WYPeT7 https://godbolt.org/z/sP6WYPeT7
- a1369209993 5y ago
  > If that were the case, wouldn't signed overflow be implementation-defined or unspecified behavior, instead of undefined behavior? No, because (among other reasons) the processor architecture might decide to trap or not trap depending the run-time values of configuration registers that the compiler doesn't know and can't control or document.
  - aw1621107 5y ago
    > the processor architecture might decide to trap or not trap depending the run-time values of configuration registers that the compiler doesn't know and can't control I'm not certain that that would fall outside implementation-defined behavior. Would something like "Program behavior on overflow is determined by processor model and configuration" not work? > or document. And even if the behavior couldn't be documented, that could be covered by unspecified behavior (assuming the language in the C standard is the same as in the C++ standard in this case)
    - a1369209993 5y ago
      > Would something like "Program behavior on overflow is determined by processor model and configuration" not work? Not sure; if nothing else, that seems like it would allow the implementation to avoid documenting any implementation-defined behaviour with a blanket "all implementation-defined behaviour is whatever the hardware happens to do when executing the relevant code".
      - aw1621107 5y ago
        I mean, that works? It's not great by any means, but it at least eliminates the ability to make the assumptions underlying more aggressive optimizations, which seems like it'd address one of the bigger concerns around said optimizations.
        a1369209993 5y ago
        Perhaps I should have phrased it as "all implementation-defined behaviour is whatever the hardware happens to do when executing whatever code the compiler happens to generate". The point of implementation-defined behaviour is that the implementation should be required to actually define the behaviour. Whereas undefined behaviour doesn't impose any requirements; the implementation can do whatever seems reasonable on a given hardware architechure. That doesn't mean that backdoor-injection malware pretending to be a implementation is a conforming implementation.
- deleted 5y ago
  [deleted]
- vyodaiken 5y ago
  I think the author of that blog was correct: the preferred path is for the compiler to provide data to the programmer to simplify the loop. For your godbolt example, use the C compiler not c++
  - aw1621107 5y ago
    > I think the author of that blog was correct: the preferred path is for the compiler to provide data to the programmer to simplify the loop. Requiring the equivalent of PGO is a rather unfortunate bar, though to be fair if you're that interested in performance it's probably something worth looking into anyways. I'm curious how how noisy an always-on warning for undersized loop variables would be, or how much code would have broken if int were changed to 64 bits on 64-bit platforms... > For your godbolt example, use the C compiler not c++ Sorry; that was a mistake on my end. The same phenomenon occurs when compiling in C mode, in any case [0]. [0]: https://godbolt.org/z/TvYrzncsc https://godbolt.org/z/TvYrzncsc

aw1621107 5y ago

> The obvious intention is that the compiler ignores overflow and lets the processor architecture make the decision. If that were the case, wouldn't signed overflow be implementation-defined or unspecified behavior, instead of undefined behavior? > Assuming that overflow doesn't happen is assuming something false. It's "false" in the same way that assuming two restrict pointers don't alias is "false". It may not be universally true for every single program and/or execution, but the compiler is explicitly allowed to disregard cases where the assumption may not hold (i.e., the compiler is allowed to "ignor[e] the situation completely"). And again, the compiler is allowed to make this assumption because undefined behavior has no defined semantics. If the compiler assumes that no undefined behavior occurs, and undefined behavior does occur, whatever happens at that point is still conforming, since the Standard says that it imposes no requirements on said program. > it doesn't "optimize" anything. ...But it does allow for optimizations? For example, assuming signed overflow can allow the compiler to unroll/vectorize loops when the loop index is not the size of a machine word [0]. Godbolt example at [1]. [0]: https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759de5a7 https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759... [1]: https://godbolt.org/z/sP6WYPeT7 https://godbolt.org/z/sP6WYPeT7

a1369209993 5y ago
> If that were the case, wouldn't signed overflow be implementation-defined or unspecified behavior, instead of undefined behavior? No, because (among other reasons) the processor architecture might decide to trap or not trap depending the run-time values of configuration registers that the compiler doesn't know and can't control or document.
- aw1621107 5y ago
  > the processor architecture might decide to trap or not trap depending the run-time values of configuration registers that the compiler doesn't know and can't control I'm not certain that that would fall outside implementation-defined behavior. Would something like "Program behavior on overflow is determined by processor model and configuration" not work? > or document. And even if the behavior couldn't be documented, that could be covered by unspecified behavior (assuming the language in the C standard is the same as in the C++ standard in this case)
  - a1369209993 5y ago
    > Would something like "Program behavior on overflow is determined by processor model and configuration" not work? Not sure; if nothing else, that seems like it would allow the implementation to avoid documenting any implementation-defined behaviour with a blanket "all implementation-defined behaviour is whatever the hardware happens to do when executing the relevant code".
    - aw1621107 5y ago
      I mean, that works? It's not great by any means, but it at least eliminates the ability to make the assumptions underlying more aggressive optimizations, which seems like it'd address one of the bigger concerns around said optimizations.
      - a1369209993 5y ago
        Perhaps I should have phrased it as "all implementation-defined behaviour is whatever the hardware happens to do when executing whatever code the compiler happens to generate". The point of implementation-defined behaviour is that the implementation should be required to actually define the behaviour. Whereas undefined behaviour doesn't impose any requirements; the implementation can do whatever seems reasonable on a given hardware architechure. That doesn't mean that backdoor-injection malware pretending to be a implementation is a conforming implementation.
deleted 5y ago
[deleted]
vyodaiken 5y ago
I think the author of that blog was correct: the preferred path is for the compiler to provide data to the programmer to simplify the loop. For your godbolt example, use the C compiler not c++
- aw1621107 5y ago
  > I think the author of that blog was correct: the preferred path is for the compiler to provide data to the programmer to simplify the loop. Requiring the equivalent of PGO is a rather unfortunate bar, though to be fair if you're that interested in performance it's probably something worth looking into anyways. I'm curious how how noisy an always-on warning for undersized loop variables would be, or how much code would have broken if int were changed to 64 bits on 64-bit platforms... > For your godbolt example, use the C compiler not c++ Sorry; that was a mistake on my end. The same phenomenon occurs when compiling in C mode, in any case [0]. [0]: https://godbolt.org/z/TvYrzncsc https://godbolt.org/z/TvYrzncsc