Il compilatore può piegare costantemente una volatile locale?

Considera questo semplice codice:

void g();

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

https://godbolt.org/z/I2kBY7

Puoi vedere che gccné clangottimizzare né ottimizzare la potenziale chiamata a g. Questo è corretto nella mia comprensione: la macchina astratta è quella di supporre che le volatilevariabili possano cambiare in qualsiasi momento (a causa di essere mappate dall'hardware), quindi piegare costantemente l' falseinizializzazione nel ifcontrollo sarebbe sbagliato.

Ma MSVC elimina completamente la chiamata g(mantenendo le letture e le scritture al volatilepensiero!). Questo comportamento è conforme allo standard?

^{Background: Occasionalmente utilizzo questo tipo di costrutto per essere in grado di attivare / disattivare l'output di debug al volo: il compilatore deve sempre leggere il valore dalla memoria, quindi cambiando quella variabile / memoria durante il debug si dovrebbe modificare il flusso di controllo di conseguenza . L'output di MSVC rilegge il valore ma lo ignora (presumibilmente a causa della costante piegatura e / o eliminazione del codice morto), che ovviamente sconfigge qui le mie intenzioni.}

modifiche:

• L'eliminazione delle letture e delle scritture volatileviene discussa qui: è consentito a un compilatore di ottimizzare una variabile volatile locale? (grazie Nathan!). Penso che lo standard sia abbondantemente chiaro che quelle letture e scritture debbano avvenire. Ma questa discussione non copre se sia legale per il compilatore dare per scontati i risultati di tali letture e ottimizzarli sulla base di ciò. Suppongo che questo sia sotto / non specificato nello standard, ma sarei felice se qualcuno mi dimostrasse che mi sbagliavo.

• Ovviamente posso creare xuna variabile non locale per risolvere il problema. Questa domanda è più per curiosità.

Penso che [intro.execution] (il numero di paragrafo vari) potrebbe essere usato per spiegare il comportamento di MSVC:

Un'istanza di ciascun oggetto con durata di memorizzazione automatica è associata a ciascuna voce nel suo blocco. Tale oggetto esiste e mantiene il suo ultimo valore memorizzato durante l'esecuzione del blocco e mentre il blocco è sospeso ...

Lo standard non consente l'eliminazione di una lettura attraverso un valore volatile, ma il paragrafo sopra potrebbe essere interpretato nel senso che consente di prevedere il valore false.

A proposito, lo standard C (N1570 6.2.4 / 2) dice che

Un oggetto esiste, ha un indirizzo costante e conserva il suo ultimo valore memorizzato per tutta la sua durata. ³⁴

---

34) Nel caso di un oggetto volatile, l'ultimo archivio non deve essere esplicito nel programma.

Non è chiaro se ci potrebbe essere un archivio non esplicito in un oggetto con durata di memorizzazione automatica nella memoria C / modello a oggetti.

TL; DR Il compilatore può fare quello che vuole su ogni accesso volatile. Ma la documentazione deve dirti: "La semantica di un accesso attraverso un valore volatile è definita dall'implementazione".

Lo standard definisce per un programma le sequenze consentite di "accessi volatili" e altri "comportamenti osservabili" (raggiunti tramite "effetti collaterali") che un'implementazione deve rispettare secondo la "regola dell'as-se".

Ma lo standard dice (la mia enfasi sul grassetto):

Bozza di lavoro, standard per il linguaggio di programmazione C ++
Numero documento: N4659
Data: 21-03-2017

§ 10.1.7.1 I qualificatori cv

5 La semantica di un accesso attraverso un valore volatile è definita dall'implementazione. [...]

Allo stesso modo per i dispositivi interattivi (la mia enfasi sul grassetto):

§ 4.6 Esecuzione del programma

5 Un'implementazione conforme che esegue un programma ben formato deve produrre lo stesso comportamento osservabile di una delle possibili esecuzioni dell'istanza corrispondente della macchina astratta con lo stesso programma e lo stesso input. [...]

7 I requisiti minimi per un'implementazione conforme sono:

(7.1) - Gli accessi attraverso i valori volatili sono valutati rigorosamente secondo le regole della macchina astratta.
(7.2) - Al termine del programma, tutti i dati scritti in file devono essere identici a uno dei possibili risultati che avrebbe prodotto l'esecuzione del programma in base alla semantica astratta.
(7.3) - Le dinamiche di input e output dei dispositivi interattivi devono avvenire in modo tale che il prompt di output sia effettivamente consegnato prima che un programma attenda l'input. Ciò che costituisce un dispositivo interattivo è definito dall'implementazione.

Questi sono collettivamente definiti comportamento osservabile del programma. [...]

(Comunque quale codice specifico viene generato per un programma non è specificato dallo standard.)

Quindi, sebbene lo standard affermi che gli accessi volatili non possono essere elusi dalle sequenze astratte di effetti collaterali astratti della macchina e conseguenti comportamenti osservabili che alcuni codici (forse) definiscono, non ci si può aspettare che qualcosa si rifletta nel codice oggetto o nel mondo reale comportamento a meno che la documentazione del compilatore non indichi cosa costituisce un accesso instabile . Idem per dispositivi interattivi.

Se sei interessato alla volatilità di fronte alle sequenze astratte di effetti collaterali astratti della macchina e / o conseguenti comportamenti osservabili che alcuni codici (forse) definiscono, allora dillo . Ma se sei interessato a quale codice oggetto corrispondente viene generato , devi interpretarlo nel contesto del tuo compilatore e compilazione .

Cronicamente le persone credono erroneamente che per accessi volatili una valutazione / lettura di una macchina astratta provochi una lettura implementata e un'assegnazione / scrittura di una macchina astratta causi una scrittura implementata. Non vi è alcuna base per questa convinzione in assenza di documentazione sull'attuazione che lo affermi. Quando / iff l'implementazione dice che in realtà fa qualcosa su un "accesso volatile", le persone sono giustificate nell'aspettarsi che qualcosa - forse, la generazione di un certo codice oggetto.

Credo che sia legale saltare l'assegno.

Il paragrafo che a tutti piace citare

34) Nel caso di un oggetto volatile, l'ultimo archivio non deve essere esplicito nel programma

non implica che un'implementazione debba presumere che tali negozi siano possibili in qualsiasi momento o per qualsiasi variabile volatile. Un'implementazione sa quali negozi sono possibili. Ad esempio, è del tutto ragionevole supporre che tali scritture implicite avvengano solo per variabili volatili che sono mappate ai registri dei dispositivi e che tale mappatura è possibile solo per variabili con collegamento esterno. Oppure un'implementazione può presumere che tali scritture si aprano solo a posizioni di memoria allineate a parole, allineate a parole.

Detto questo, penso che il comportamento di MSVC sia un bug. Non esiste un motivo reale per ottimizzare la chiamata. Tale ottimizzazione può essere conforme, ma è inutilmente malvagia.