3 ms·

Sure it can. That code path has unconditional UB and thus it is not valid.

by saagarjha 5mo ago

shakna 5mo ago
Only if there would be no side-effects. Which there are.
- saagarjha 5mo ago
  No this is irrelevant for making this decision
  - shakna 5mo ago
    I've mentioned elsewhere the standards, and compilers as well, disagreeing with you here. But feel free to run against the various compilers through godbolt. [0] They won't optimise the branch away. Access to a volatile, must be preserved, in the order that they exist. No optimisation, UB or otherwise, is allowed to impede that. Because an access is a side-effect. [0] https://godbolt.org/z/85cGhq3Ta https://godbolt.org/z/85cGhq3Ta
    - saagarjha 5mo ago
      That they won’t is as most a courtesy to you but they are not required to do this.
      - shakna 5mo ago
        > Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously. I quoted the C standard, first. Not compiler behaviour. I showed where it requires the compiler not to optimise this. How about, instead of one-line throwaway disagreements, you point out where they are permitted to do this, instead?
        dwattttt 5mo ago
        The compiler is required to not optimise out reads/writes through volatile. That's unrelated to code also having UB: you can't sprinkle volatile through arbitrary UB and suddenly have it be defined. > A compliant compiler is only free to optimise away, where it can determine there are no side-effects A compliant compiler is also allowed to assume UB cannot occur.
    - zahlman 5mo ago
      Compilers not doing something is not a demonstration that they are not actually allowed to do that thing.
- nilamo 5mo ago
  This looks like a long back and fourth, that can easily be solved by a minute or two on godbolt...
  - aw1621107 5mo ago
    > that can easily be solved by a minute or two on godbolt... Unfortunately it's not that simple when it comes to UB. If the snippet in question does in fact exhibit UB then there's no guarantee whatever Godbolt shows will generalize to other programs/versions/compilers/environments/etc.
    - nilamo 5mo ago
      That's very funny to me. A) x is always removed. B) no, it's never removed if volatile. But neither person can prove what a compiler will actually do, despite claiming they'll always act a certain way given 5 lines of code.
      - saagarjha 5mo ago
        I made the weaker claim that x can be removed. This is something I could prove with compiler output but I would have to find a compiler willing to make this optimization which is not something I can guarantee.
      - tialaramex 5mo ago
        Also, at behavioural edges what you'll see on Godbolt is compiler bugs. So you learn nothing about what should happen. All popular modern C++ compilers have known bugs and while I'm sure there are C compilers with no known bugs that will be because nobody tested very hard.
      - dwattttt 5mo ago
        I have watched a compiler flip between emitting the code I expected (despite it having UB), and emitting unexpected code after a minor update. What you observe a compiler do when there's UB is not at all something you can rely on.
      - 5mo ago

Sure it can. That code path has unconditional UB and thus it is not valid.

shakna 5mo ago

Only if there would be no side-effects. Which there are.

saagarjha 5mo ago
No this is irrelevant for making this decision
- shakna 5mo ago
  I've mentioned elsewhere the standards, and compilers as well, disagreeing with you here. But feel free to run against the various compilers through godbolt. [0] They won't optimise the branch away. Access to a volatile, must be preserved, in the order that they exist. No optimisation, UB or otherwise, is allowed to impede that. Because an access is a side-effect. [0] https://godbolt.org/z/85cGhq3Ta https://godbolt.org/z/85cGhq3Ta
  - saagarjha 5mo ago
    That they won’t is as most a courtesy to you but they are not required to do this.
    - shakna 5mo ago
      > Furthermore, at every sequence point the value last stored in the object shall agree with that prescribed by the abstract machine, except as modified by the unknown factors mentioned previously. I quoted the C standard, first. Not compiler behaviour. I showed where it requires the compiler not to optimise this. How about, instead of one-line throwaway disagreements, you point out where they are permitted to do this, instead?
      - dwattttt 5mo ago
        The compiler is required to not optimise out reads/writes through volatile. That's unrelated to code also having UB: you can't sprinkle volatile through arbitrary UB and suddenly have it be defined. > A compliant compiler is only free to optimise away, where it can determine there are no side-effects A compliant compiler is also allowed to assume UB cannot occur.
  - zahlman 5mo ago
    Compilers not doing something is not a demonstration that they are not actually allowed to do that thing.
nilamo 5mo ago
This looks like a long back and fourth, that can easily be solved by a minute or two on godbolt...
- aw1621107 5mo ago
  > that can easily be solved by a minute or two on godbolt... Unfortunately it's not that simple when it comes to UB. If the snippet in question does in fact exhibit UB then there's no guarantee whatever Godbolt shows will generalize to other programs/versions/compilers/environments/etc.
  - nilamo 5mo ago
    That's very funny to me. A) x is always removed. B) no, it's never removed if volatile. But neither person can prove what a compiler will actually do, despite claiming they'll always act a certain way given 5 lines of code.
    - saagarjha 5mo ago
      I made the weaker claim that x can be removed. This is something I could prove with compiler output but I would have to find a compiler willing to make this optimization which is not something I can guarantee.
    - tialaramex 5mo ago
      Also, at behavioural edges what you'll see on Godbolt is compiler bugs. So you learn nothing about what should happen. All popular modern C++ compilers have known bugs and while I'm sure there are C compilers with no known bugs that will be because nobody tested very hard.
    - dwattttt 5mo ago
      I have watched a compiler flip between emitting the code I expected (despite it having UB), and emitting unexpected code after a minor update. What you observe a compiler do when there's UB is not at all something you can rely on.
    - 5mo ago