On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc, <gcc@gcc.gnu.org> wrote:
> 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. > The C++ committee is currently considering this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1494r2.html I think this explicit barrier-like solution is better than trying to use volatile accesses to achieve something similar. > > >
