Hello, On Thu, 13 Jan 2022, Martin Uecker 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. But right now that's equivalent to making it observable, because we don't have any other terms than observable or undefined. As aluded to later you would have to introduce a new concept, something pseudo-observable, which you then started doing. So, see below. > > 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. Using volatile accesses for memory mapped IO is a much stronger use-case than your wish of using volatile accesses to block moving of UB as a debugging aid, and the former absolutely needs some guarantees, so I don't think it would be a compromise at all. Mkaing volatile not be observable would break the C language. > > 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) First you need to define "point in time", a concept which doesn't exist yet in C. The obvious choice is of course observable behaviour in the execution environment and its specified ordering from the abstract machine, as clarified via sequence points. With that your "at the point in time" becomes something like "after all side effects of previous sequence point, but strictly before all side effects of next sequence point". But doing that would have very far reaching consequences, as already stated in this thread. The above would basically make undefined behaviour be reliably countable, and all implementations would need to produce the same counts of UB. That in turn disables many code movement and commonization transformations, e.g. this: int a = ..., b = ...; int x = a + b; int y = a + b; can't be transformed into "y = x = a + b" anymore, because the addition _might_ overflow, and if it does you have two UBs originally but would have one UB after. I know that you don't want to inhibit this or similar transformations, but that would be the result of making UB countable, which is the result of forcing UB to happen at specific points in time. So, I continue to see problems in precisely specifying what you want, _but not more_. I think all models in which you order the happening of UB with respect to existing side effects (per abstract machine, so it includes modification of objects!) have this same problem, it always becomes a side effect itself (one where you don't specify what actually happens, but a side effect nontheless) and hence becomes observable. Ciao, Michael.
