https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82744
Bug ID: 82744
Summary: Better handling equivalence+common for FORTRAN
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Target Milestone: ---
Hi,
Given below fortran code:
subroutine test (res1, res2)
integer i, j
real*8 a(100) , b(100) , c(100) , d(100)
common /area/ a, b, c, d
real*8 src1(100), temp1(100), temp2(100), src2(100)
equivalence (src1, a), (src2, b), (temp1, c), (temp2, d)
real*8 res1(100,100), res2(100,100)
do 20 j=1,100
do 30 i=1,100
temp1(i) = 1.0
temp2(i) = 2.0
temp1(i) = temp1(i) * src1(i)
temp2(i) = temp2(i) * src2(i)
res1(i,j) = temp2(i) * 3.0 + res1(i,j) / 2
res2(i,j) = temp1(i) * 3.0 + res2(i,j) / 2
30 continue
20 continue
return
end
Fortran FE generates type like:
union
{
real(kind=8) src1[100];
real(kind=8) a[100];
real(kind=8) src2[100];
real(kind=8) b[100];
real(kind=8) temp1[100];
real(kind=8) c[100];
real(kind=8) temp2[100];
real(kind=8) d[100];
}
but (src1/a), (src2/b), (temp1/c), (temp2/d) have different DECL_FIELD_OFFSET.
There are two questions here:
A) Should Fortran FE generate better type here? In this case, it could be
structure of unions. Thus to make middle-end's life a bit easier. This maybe
not always straightforward, considering below example:
real*8 a(100) , b(100) , c(100) , d(100)
common /area/ a, b, c, d
real*8 src1(100), temp1(100), temp2(1000), src2(100)
equivalence (src1, a), (src2, b), (temp1, c), (temp2, d)
B) Support arbitrary offset layout in union type. This is not easy either
because we can have arbitrary overlap with equivalence. We also need to check
if a field is the "last" one so it can access beyond size of union/record.
Again, this is not easy with arbitrary layout, though FE may help by setting
some flags.
Back to above example, there are various missed optimizations about dead store
and redundant load.
For the moment, I will categorize this one as middle-end issue.
Thanks.
