Nathan Sidwell writes: > Dale Johannesen wrote: > > > And we don't have to document the behavior at all; it is not documented > > now. > I disagree. It's not documented explicitly in gcc now, because it is doing > what the std permits, and so documented there. We should document either > > a) that current gcc is not breaking the std, and Mike's example is invalid > code, if one expects a volatile read. This would be a FAQ like thing. > > b) amend the compiler to do a volatile read, and document the extension. > This should go in extend.texi > > Documentation for (b) is necessary so that programmers can rely on the > extension (and understand why some other compiler might not do what they > want) _and_ so that gcc maintainers know about it.
And it is difficult to specify exactly where volatile casts should be preserved and where they may legitimately be optimized away, so we may well make mistakes in doing so, and end up with an ill-defined extension. The C Standard already has well-defined semantics for this, and we are not AFAIAA in the business of redesigning C. What matters is the volatility of the _object_, and this is at least reasonably easy to understand. This is a bad extension to gcc and will cause much trouble, just like the old guarantee to preserve empty loops. Andrew.
