4 ms·

Your block of code can be (and absolutely is) optimized to output zero directly (in c, because the assembly is easier to read): https://c.godbolt.org/z/qe3f4K

Your block of code can be (and absolutely is) optimized to output zero directly (in c, because the assembly is easier to read): https://c.godbolt.org/z/qe3f4K https://c.godbolt.org/z/qe3f4K `*(&i+1)` dereferences the pointer "one past the end" which is UB.

TrianguloY 6y ago
And I agree, with an UB the original code is undefined and so any optimization is not right nor wrong, simply keep that UB. But then, why such a long article for a code whose second line is a UB ('p+1' is undefined)?
- gizmo686 6y ago
  uintptr_t ip = (uintptr_t)(p+1); Is perfectly defined. What is undefined is converting ip back to a pointer and writing to it, which the original program never does.
  - TrianguloY 6y ago
    Hmm, I think I understand now. So now I think it's the first optimization the one that is wrong. If you replace a variable with another, don't you need to keep information of the original variable? I mean, if a==b and you do *a=1 you can replace it with *b=1, but then you need to keep the information that 'a' was written to, so other optimizations (the third one) don't think it wasn't. Or am I missing something else here? Edit: sorry for the code block, otherwise the asterisks are removed.
    - Dylan16807 6y ago
      > If you replace a variable with another, don't you need to keep information of the original variable? Note that ip and iq are integers. If you can't replace integers freely, it makes it really hard to optimize arithmetic.
  - deleted 6y ago
    [deleted]
- Dr_Emann 6y ago
  Because there is no UB in the original program. It constructs a pointer to the "one past the end" element, but that is fine, and the original program never dereferences that pointer. Again: there is no UB in the original program.
  - magicalhippo 6y ago
    There's clearly potential for pointer aliasing in the program, isn't that UB?
- fanf2 6y ago
  No, p+1 is OK because you are allowed to make a pointer one past the end in C (so that common pointer loops work as expected) but you cannot dereference them.

TrianguloY 6y ago

And I agree, with an UB the original code is undefined and so any optimization is not right nor wrong, simply keep that UB. But then, why such a long article for a code whose second line is a UB ('p+1' is undefined)?

gizmo686 6y ago
uintptr_t ip = (uintptr_t)(p+1); Is perfectly defined. What is undefined is converting ip back to a pointer and writing to it, which the original program never does.
- TrianguloY 6y ago
  Hmm, I think I understand now. So now I think it's the first optimization the one that is wrong. If you replace a variable with another, don't you need to keep information of the original variable? I mean, if a==b and you do *a=1 you can replace it with *b=1, but then you need to keep the information that 'a' was written to, so other optimizations (the third one) don't think it wasn't. Or am I missing something else here? Edit: sorry for the code block, otherwise the asterisks are removed.
  - Dylan16807 6y ago
    > If you replace a variable with another, don't you need to keep information of the original variable? Note that ip and iq are integers. If you can't replace integers freely, it makes it really hard to optimize arithmetic.
- deleted 6y ago
  [deleted]
Dr_Emann 6y ago
Because there is no UB in the original program. It constructs a pointer to the "one past the end" element, but that is fine, and the original program never dereferences that pointer. Again: there is no UB in the original program.
- magicalhippo 6y ago
  There's clearly potential for pointer aliasing in the program, isn't that UB?
fanf2 6y ago
No, p+1 is OK because you are allowed to make a pointer one past the end in C (so that common pointer loops work as expected) but you cannot dereference them.