¿Se le permite al compilador doblar constantemente un volátil local?

Considere este código simple:

void g();

void foo()
{
    volatile bool x = false;
    if (x)
        g();
}

https://godbolt.org/z/I2kBY7

Puede ver que gccni clangoptimizar la llamada potencial a g. En mi opinión, esto es correcto: la máquina abstracta debe suponer que las volatilevariables pueden cambiar en cualquier momento (debido, por ejemplo, a un mapeo de hardware), por lo que el plegado constante de la falseinicialización en la ifcomprobación sería incorrecto.

Pero MSVC elimina la llamada por gcompleto ( volatile¡aunque mantiene las lecturas y escrituras en el !). ¿Es este comportamiento compatible con el estándar?

^{Antecedentes: ocasionalmente uso este tipo de construcción para poder activar / desactivar la salida de depuración sobre la marcha: el compilador siempre debe leer el valor de la memoria, por lo que cambiar esa variable / memoria durante la depuración debería modificar el flujo de control en consecuencia . La salida de MSVC vuelve a leer el valor, pero lo ignora (presumiblemente debido a la eliminación constante del código y / o eliminación del código muerto), lo que, por supuesto, derrota mis intenciones aquí.}

Ediciones:

• volatileAquí se analiza la eliminación de las lecturas y escrituras : ¿está permitido que un compilador optimice una variable volátil local? (¡Gracias Nathan!). Creo que el estándar es muy claro que esas lecturas y escrituras deben suceder. Pero esa discusión no cubre si es legal que el compilador tome los resultados de esas lecturas por sentado y optimice en función de eso. Supongo que esto está sub / no especificado en el estándar, pero sería feliz si alguien demostrara que estoy equivocado.

• Por supuesto, puedo hacer xuna variable no local para evitar el problema. Esta pregunta es más por curiosidad.

Creo que [intro.execution] (el número de párrafo varía) podría usarse para explicar el comportamiento de MSVC:

Una instancia de cada objeto con duración de almacenamiento automática está asociada con cada entrada en su bloque. Tal objeto existe y retiene su último valor almacenado durante la ejecución del bloque y mientras el bloque está suspendido ...

El estándar no permite la eliminación de una lectura a través de un valor de gl volátil, pero el párrafo anterior podría interpretarse como que permite predecir el valor false.

Por cierto, el estándar C (N1570 6.2.4 / 2) dice que

Existe un objeto, tiene una dirección constante y conserva su último valor almacenado durante toda su vida útil. ³⁴

---

34) En el caso de un objeto volátil, la última tienda no necesita ser explícita en el programa.

No está claro si podría haber un almacenamiento no explícito en un objeto con duración de almacenamiento automático en la memoria C / modelo de objeto.

TL; DR El compilador puede hacer lo que quiera en cada acceso volátil. Pero la documentación tiene que decirle: "La semántica de un acceso a través de un valor de volátil está definida por la implementación".

El estándar define para un programa secuencias permitidas de "accesos volátiles" y otros "comportamientos observables" (logrados mediante "efectos secundarios") que una implementación debe respetar según "la regla" como si ".

Pero el estándar dice (mi énfasis en negrita):

Borrador de trabajo, estándar para lenguaje de programación C ++
Número de documento: N4659
Fecha: 2017-03-21

§ 10.1.7.1 Los calificadores cv

5 La semántica de un acceso a través de un valor de gl volátil está definida por la implementación. [...]

Del mismo modo para dispositivos interactivos (mi énfasis en negrita):

§ 4.6 Ejecución del programa

5 Una implementación conforme que ejecute un programa bien formado producirá el mismo comportamiento observable que una de las posibles ejecuciones de la instancia correspondiente de la máquina abstracta con el mismo programa y la misma entrada. [...]

7 Los requisitos mínimos en una implementación conforme son:

(7.1) - Los accesos a través de valores volátiles se evalúan estrictamente de acuerdo con las reglas de la máquina abstracta.
(7.2) - Al finalizar el programa, todos los datos escritos en los archivos serán idénticos a uno de los posibles resultados que la ejecución del programa de acuerdo con la semántica abstracta habría producido.
(7.3) - La dinámica de entrada y salida de los dispositivos interactivos se llevará a cabo de tal manera que la salida de solicitud se entregue antes de que un programa espere la entrada. Lo que constituye un dispositivo interactivo está definido por la implementación.

Estos colectivamente se conocen como el comportamiento observable del programa. [...]

(De todos modos, el código específico que se genera para un programa no está especificado por el estándar).

Entonces, aunque el estándar dice que los accesos volátiles no se pueden eludir de las secuencias abstractas de los efectos secundarios abstractos de la máquina y los comportamientos observables consecuentes que algunos códigos (tal vez) definen, no puede esperar que nada se refleje en el código objeto o en el mundo real comportamiento a menos que la documentación del compilador le diga qué constituye un acceso volátil . Lo mismo para dispositivos interactivos.

Si está interesado en la volatilidad frente a las secuencias abstractas de los efectos secundarios abstractos de la máquina y / o los comportamientos observables consiguientes que algunos códigos (tal vez) definen , dígalo . Pero si está interesado en qué código objeto correspondiente se genera , debe interpretarlo en el contexto de su compilador y compilación .

Crónicamente, las personas creen erróneamente que para los accesos volátiles, una evaluación / lectura de máquina abstracta provoca una lectura implementada y una asignación / escritura de máquina abstracta provoca una escritura implementada. No hay ninguna base para esta creencia en ausencia de documentación de implementación que lo diga Cuando / si la implementación dice que en realidad hace algo en un "acceso volátil", la gente está justificada en esperar que algo, tal vez, la generación de cierto código objeto.

Creo que es legal omitir el cheque.

El párrafo que a todos les gusta citar

34) En el caso de un objeto volátil, la última tienda no necesita ser explícita en el programa

no implica que una implementación deba asumir que tales almacenes son posibles en cualquier momento o para cualquier variable volátil. Una implementación sabe qué tiendas son posibles. Por ejemplo, es completamente razonable suponer que tales escrituras implícitas solo ocurren para variables volátiles que se asignan a registros de dispositivos, y que dicha asignación solo es posible para variables con enlace externo. O una implementación puede suponer que tales escrituras solo se transfieren a ubicaciones de memoria alineadas con el tamaño de las palabras.

Dicho esto, creo que el comportamiento de MSVC es un error. No hay ninguna razón en el mundo real para optimizar la llamada. Tal optimización puede ser compatible, pero es innecesariamente malvada.