(sorry, with intended statement this time) > From: Geoff Keating <[EMAIL PROTECTED]> > On 22/07/2005, at 7:15 PM, Paul Schlie wrote: > >>> Geoffrey Keating writes: > >>> without 'volatile', then this object cannot be modified unknown to >>> the implementation, even if someone also writes '(*(volatile int *)&i) >>> = 1'. >> >> - merely means: treat the object being referenced as volatile >> qualified int object (as the standard specifies, although it may result >> in an undefined behavior, nothing more or less; as although the object >> may have not been initially declared as being volatile, the program >> within the context of this particular references has asserted that it >> must be treated as such, thereby implying it's value must be assigned, >> and/or presumed to have been possibly modified beyond the logical view >> of the program). > > It doesn't imply that. All it implies is that *from this access* the > compiler cannot assume that the object is not "modified in ways > unknown to the implementation". From other accesses, including from > the original declaration (and its initializer if any), the > implementation may be able to make that deduction. If, and only if, > the implementation can make that deduction, then it can perform > optimizations.
- It can not, C's object's reference access model is based upon an object's classification within the context of it's specified access. (as it's lvalue "locator value" is specified as defining the object being referenced.) > In this example: > > int i = 0; > while (*(volatile int *)&i == 0) ; > > then the implementation can make that assumption, and optimise the > loop into an infinite loop that does not test 'i', because the '= 0;' > performs a store to a non-volatile object 'i' which therefore cannot > be modified in ways unknown to the implementation and therefore will > always be zero. - It can not, as the object being referenced is unambiguously specified as a volatile object, i.e. within the context of this reference it must assume that it's state may be affected by forces beyond the scope of the logical program by definition. (Which may or may not be consistent with it's previous declarations; where if not, may or may not affect the logical integrity of an implementation's volatile object allocation and/or semantic presumptions; in which case if deducible, a warning without any attempt to alter the behavior/assertions specified would likely be most useful.) Correspondingly for example: - all qualifier based behavior/assertions should be similarly scoped. - and further, pointers should be simultaneously included in all alias sets that their references are cast to within their respective scopes without needing to explicitly define them as a union of referenced types, as C's object reference based model implies they should ideally safely be. Overall, someone should really re-think and hopefully eliminate GCC's predisposition to go seemingly out of its way to identify opportunities to obfuscate compiled code behaviors based on the justification that it's enabled to do so for undefined behaviors, as all such optimizations will only truly result in unexpected behaviors, without benefit to anyone; although warning of their presence is likely universally useful.
