https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> --- I'm not working on this. The comment#12 testcase shows the diagnostic happening but it works at runtime because we a) honor "must-alias" for QOI reasons and the accesses are not enough obfuscated (and I don't know how to obfuscate on the fortran side). Adjusted testcase: program test use iso_c_binding integer(c_int) :: i integer :: j common /a/ i bind(c) :: /a/ interface subroutine foo() bind(c) end subroutine end interface i = 42 call foo() j = i print *, j end program test --- extern int a; void foo (void) { a = -1; } where we end up with __MEM <int> (&a) = _Literal (int) -1; j = _Literal (int) -1; with -O -fno-tree-fre -fno-tree-dominator-opts we see __MEM <int> (&a) = _Literal (int) -1; _1 = a.i; j = _1; but clearly this way around is even valid when taking the struct as prevailing and using the component as access type. So I think we should be safe?