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?