Hmmmmm. It's late, but FWIW I think this comment from Martin from last year might be relevant: https://news.ycombinator.com/item?id=40838721 And I'm guessing the note that was added is fn#150 in C23. Volatile accesses aren't general memory barriers, but I think Martin's point is the potential for UB behavior means the compiler has to preserve the sequence order of the potentially UB operation relative to the volatile access.
The potential for undefined behavior means ... the potential for a situation to emerge where no further requirements apply.
If you regard undefined behavior as having ordering requirements, it's game over for optimization (not to mention the current understanding of undefined behavior). Any time you have bona fide observable effects near calculation, you are hamstrung, because the potential for UB is in every nook and cranny, around every corner.
I think it's perfectly fine for the division by zero to occur before the output is produced and flushed, in that example. The UB of a bad division can time travel because a division is assumed not to have UB and can be reordered before a visible effect to which it is not related (the effect doesn't require the result of the division, nor does the division require an output tied to the production of the visible effect).
What these people are looking for is a safe calculation mode in which a bad division does something that is well-defined, like raise an exception that can be caught. That is then deemed visible, and must not be reordered w.r.t. other visible effects. And while it does hamper optimization, it is a translation mode that can be enabled or disabled around a block of code. If the programmer is certain there is no bad division, or else don't care about that being ordered w.r.t. a visible effect, then they declare a low safety level. (Which, this still being C, could be the default level).
As long as C standardization thinking remains obtuse or hostile w.r.t. this type of programmer-controlled safety level concept, they will be forever confounded by dilemmas caused by wanting intuitive outcomes that logically require undefined behavior to be partially defined.
Both the C and C++ standardization committees have decided that even when there is undefined behavior the program is partially defined. But nobody is confounded by this.
Suppose we require it that the output flush must take place before the behavior becomes undefined by a bad division. That doesn't buy much because the visible effect is only that some bytes are passed from the stdout stream to the host environment. The undefined behavior is allowed to bring down that entire environment though; so our requirements don't add up to the certainty that the output has been transmitted out of that host system to some output device (display, serial or network, ...), or committed to durable storage. (The latter could be wiped out by the UB, even if so).
Basically, standardization groups should be dissolved long before they devolve into stuff like this, where they are just creating churn for the sake of their own continuation.
We don't need to suppose this, as this is what is already required in C. You are right that when I/O is performed it is up to the host system what happens, and it is also possible that on UB the whole system crashes if it is poor. But this is outside the jurisdiction of the C language.
What it is important though is that where C spec can be complemented by other specification that add reasonable requirements about the host system, e.g. that it does not crash then a program misbehaves or that I/O is performed according to certain rules, certain safety properties can then be ensured. This would not be possible without UB being restricted in this way. As compilers are now being fixed, this is not churn but a real world improvement people have asked for.
