+++ This bug was initially created as a clone of Bug #30522 +++ Setting the VOLATILE attribute to a host- or use-associated variable currently marks the variable everywhere as VOLATILE. The attribute should be, however, restricted to the scope. (This is a missed optimization only.) Possible implementation: decl.c: gfc_match_volatile case MATCH_YES: /* If the use- or host-associated symbol is not volatile, we clone it. */ if (!sym->attr.volatile_ && sym->ns != gfc_current_ns) { /* note somewhere that in this namespace VOLATILE is needed, e.g. by cloning the variable here and setting below the attribute only to the cloned variable. And then put a check in trans-decl.c in e.g. gfc_generate_function_code near generate_local_vars to actually mark this variable as volatile; be careful that the variable should be "external volatile" not a new local variable. */ } if (gfc_add_volatile (&sym->attr, sym->name, &gfc_current_locus) Test case: See PR30522's volatile10.f90 (search for TODO). Maybe the fact that -fdump-tree-original does not show the VOLATILE attribute for module variables could be solved as collateral damage.
Confirmed.
Restricting can be done via casting to volatile - then it is only *(volatile int *)&i That needs then to be applies in all expressions.
There were some changes with the optimization and the volatile attribute with release 7.0. Maybe check if this issue is still present?
This PR has been filed almost twelve years ago without any feedback for almost ten years. It is very unlikely that this missed optimization exists in real code. In addition I think this optimization is the user's responsibility and not of the compiler: using VOLATILE in a hot spot does not make sense for me. I am closing as WONTFIX, if the problem occurs in a real code, the user will open a new PR with an actual test.