3 ms·

Which is logically equivalent to imposing no requirements. "ignoring the situation completely with unpredictable results" does not meaningfully constrain the po

Which is logically equivalent to imposing no requirements. "ignoring the situation completely with unpredictable results" does not meaningfully constrain the possible behaviors.

mpweiher 3y ago
That turns out not to be the case. “Ignoring” is not “taking action based on” Ignoring is, for example, ignoring the fact that an array access is out of bounds and performing the array access. Ignoring is not noticing that there is undefined behavior and removing the access and the entire loop that contains the access. Or a safety check.
- mike_hock 3y ago
  So, generally, optimizations shouldn't be allowed? Dead code removal shouldn't be allowed? Substituting constants shouldn't be allowed? Because "ignoring" UB is pretty much what the compiler did, and then let its optimization passes run to their conclusion. > ignoring the fact that an array access is out of bounds and performing the array access The idea that this is even meaningful is precisely the "portable assembler" misconception.
  - mpweiher 3y ago
    Except the misconception is that it is not. "Committee did not want to force programmers into writing portably, to preclude the use of C as a “high-level assembler:” https://www.open-std.org/JTC1/SC22/WG14/www/docs/n897.pdf https://www.open-std.org/JTC1/SC22/WG14/www/docs/n897.pdf p10, line 39 "C code can be portable. " line 30
- muldvarp 3y ago
  > ignoring the fact that an array access is out of bounds and performing the array access This doesn't mean anything. The standard imposes no requirements that an array access is translated into a memory access by the compiler. And that's a good thing because it enables optimizations that can be critical to achieve decent performance. Assume for example that the compiler is able to prove (after inlining) that all elements of an array are equal to zero. This array is then used in a loop where in each iteration an index into this array is calculated and the corresponding array element is added to an accumulator. If the standard were to impose a rule that array accesses have to correspond to memory accesses, this code could not be optimized because one of the computed indices might lie outside of the array and the compiler is then forced to produce assembly that performs the memory access. With UB, however, the compiler is allowed to assume that all accesses to the array are valid and will be able to completely remove the (very cache-unfriendly) loop.

Which is logically equivalent to imposing no requirements. "ignoring the situation completely with unpredictable results" does not meaningfully constrain the possible behaviors.

mpweiher 3y ago

That turns out not to be the case. “Ignoring” is not “taking action based on” Ignoring is, for example, ignoring the fact that an array access is out of bounds and performing the array access. Ignoring is not noticing that there is undefined behavior and removing the access and the entire loop that contains the access. Or a safety check.

mike_hock 3y ago
So, generally, optimizations shouldn't be allowed? Dead code removal shouldn't be allowed? Substituting constants shouldn't be allowed? Because "ignoring" UB is pretty much what the compiler did, and then let its optimization passes run to their conclusion. > ignoring the fact that an array access is out of bounds and performing the array access The idea that this is even meaningful is precisely the "portable assembler" misconception.
- mpweiher 3y ago
  Except the misconception is that it is not. "Committee did not want to force programmers into writing portably, to preclude the use of C as a “high-level assembler:” https://www.open-std.org/JTC1/SC22/WG14/www/docs/n897.pdf https://www.open-std.org/JTC1/SC22/WG14/www/docs/n897.pdf p10, line 39 "C code can be portable. " line 30
muldvarp 3y ago
> ignoring the fact that an array access is out of bounds and performing the array access This doesn't mean anything. The standard imposes no requirements that an array access is translated into a memory access by the compiler. And that's a good thing because it enables optimizations that can be critical to achieve decent performance. Assume for example that the compiler is able to prove (after inlining) that all elements of an array are equal to zero. This array is then used in a loop where in each iteration an index into this array is calculated and the corresponding array element is added to an accumulator. If the standard were to impose a rule that array accesses have to correspond to memory accesses, this code could not be optimized because one of the computed indices might lie outside of the array and the compiler is then forced to produce assembly that performs the memory access. With UB, however, the compiler is allowed to assume that all accesses to the array are valid and will be able to completely remove the (very cache-unfriendly) loop.