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.]
