https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #23 from Tobias Burnus <burnus at gcc dot gnu.org> --- I have the feeling that some other use also disagrees between ME and FE/Fortran semantics assumptions. I just run into PR 92703: if one comments the unrelated 'foo', with -O0 one gets the expected 'stop 2' but with -O1 one gets 'stop 21' as (effectively) the 'class.20._data = &var;' has been optimized away. — For that PR, to properly handle Fortran semantic, a copy of 'var' had to be created and used instead. I think that would have solved the alias/ME problem for *that* usage/test case. Still, I fear that similar test cases can be created where for -O0 the executable produces the correct result – but where with optimization, the result will be wrong. Based on the test case in PR 92703, I wonder about types like: type t integer, allocatable :: A integer, pointer :: P end type t type(t) :: var call foo(var) 'var' has no pointer/target attribute and, hence, it cannot alias (or if it does as in 'call bar(var, var)' it may not be modified in bar). – Also 'var%A' cannot alias – but 'var%P' can – as it has the pointer attribute. If 'foo' has 'intent(in)' for 'var', 'var' and 'var%A' may not be modified nor the pointer address (pointer association) of 'var%P'. But the value of 'var%P' may. With CLASS and descriptor handling with BIND(C) [cf. this PR], I fear there are extra issues due to the auxiliary variables/wrappers generated by the FE. [Besides the general issue of Fortran semantic and mapping it to TYPE_RESTRICT and 'fn spec', I have also the feeling that such auxiliary vars cause breakage as they do not always follow the Fortran semantic.]