Am Donnerstag, den 13.01.2022, 16:45 +0000 schrieb Michael Matz: > Hello, > > On Tue, 11 Jan 2022, Martin Uecker via Gcc wrote: > > > > Handling all volatile accesses in the > > > very same way would be possible but quite some work I don't > > > see much value in. > > > > I see some value. > > > > But an alternative could be to remove volatile > > from the observable behavior in the standard > > or make it implementation-defined whether it > > is observable or not. > > But you are actually arguing for making UB be observable
No, I am arguing for UB not to have the power to go back in time and change previous defined observable behavior. The reason is that it makes it impossible to give any guarantees about partial executions of a program e.g. that a transaction completed or privileges were dropped or a log message went out to the log server), when there is the possibility that later there could be some UB in the program. Making UB observable would be even stronger. For example I do not mind a compiler sinking a division by zero across other observable behavior, which would not be possible if we consider the trap to be observable. > (which then directly implies an ordering > with respect to volatile accesses). Yes, it would, but "no time-travel" only implies some weaker constraints for UB and only if it actually traps or could affect observable behavior in other ways. For I/O using function calls these constraints are already fulfilled. > That's > much different from making volatile not be > observable anymore (which obviously would > be a bad idea), and is also much harder to I tend to agree that volatile should be considered observable. But volatile is a bit implementation-defined anyway, so this would be a compromise so that implementations do not have to make all the implied changes if we revise the meaning of UB. > do, it's the nature of undefined behaviour > to be hard to define :) > > Well, what you _actually_ want is an implied > dependency between some UB and volatile accesses > (and _only_ those, not e.g. with other UB), and the > difficulty now is to define "some" and to create > the dependency without making that specific UB > to be properly observable. Yes, this is what I actually want. > I think to define this > all rigorously seems futile (you need a new > category between observable and UB), so it comes > down to compiler QoI on a case by case basis. We would simply change UB to mean "arbitrary behavior at the point of time the erraneous construct is encountered at run-time" and not "the complete program is invalid all together". I see no problem in specifying this (even in a formally precise way) Martin
