Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: "volatile" on variables and current processors Date: Mon, 19 Aug 2019 17:08:23 -0700 Organization: None to speak of Lines: 64 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="eda0362a42d89c1a502f45f546af142c"; logging-data="26034"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Uw433f4Ohj+YqjJyYcUIJ" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:pXRb0NJv+vzUX++Xj6UQofe6+2s= sha1:RvTK8Sq4A3jUjzomvt72NpUVjBk= Xref: csiph.com comp.lang.c++:67791 red floyd writes: > On 8/19/2019 1:56 PM, Vir Campestris wrote: >> In the old days volatile on a variable meant putting it in memory, not >> holding it in a register. That was easy. >> > > No. That's not what volatile means. ISO/IEC 14882:2003 7.1.5.1/8 says > that volatile is an instruction to the optimizer. > > "volatile is a hint to the implementation to avoid aggressive > optimization involving the object because the value of the object > might be changed by means undetectable by an implementation." > > DISCLAIMER: C++03 is the latest copy of the standard that I have. > Can someone check a newer version and see if that's still what is > indicated? ISO/IEC 14882:2011(E) 7.1.6.1 [dcl.type.cv] p6-7: 6 If an attempt is made to refer to an object defined with a volatile-qualified type through the use of a glvalue with a non-volatile-qualified type, the program behavior is undefined. 7 [ Note: volatile is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation. See 1.9 for detailed semantics. In general, the semantics of volatile are intended to be the same in C++ as they are in C. — end note ] 1.9 [intro.execution] paragraph 8 says: 8 The least requirements on a conforming implementation are: — Access to volatile objects are evaluated strictly according to the rules of the abstract machine. [...] I don't have a copy of the C++17 standard, but N4700 (a draft of the C++17 standard) 10.1.7.1 [dcl.type.cv] p5-6 says: 5 The semantics of an access through a volatile glvalue are implementation-defined. If an attempt is made to access an object defined with a volatile-qualified type through the use of a non-volatile glvalue, the behavior is undefined. 6 [ Note: volatile is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation. Furthermore, for some implementations, volatile might indicate that special hardware instructions are required to access the object. See 4.6 for detailed semantics. In general, the semantics of volatile are intended to be the same in C++ as they are in C. — end note ] 4.6 [intro.execution] p7 says: 7 The least requirements on a conforming implementation are: (7.1) — Accesses through volatile glvalues are evaluated strictly according to the rules of the abstract machine. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */