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 (which then directly implies an ordering with respect to volatile accesses). That's much different from making volatile not be observable anymore (which obviously would be a bad idea), and is also much harder to 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. 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. Ciao, Michael.
