http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36842
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-09-07
09:13:07 UTC ---
At least I fail how the compiler can know whether the arguments alias or not.
For an illustration, use:
real(kind=kind(1.0d0)), target :: data(5,5)
data = Reshape([((i*10+j, i = 1, 5), j=1,5)], [5,5])
Rx => data(1,:)
Ry => data
for the actual argument. You will get different results with the current code,
Ry(:,n) = Ry(:,n) * Rx(:)
and with a loop which simply assigns it without a temporary,
do m = 1, size(Rx)
Ry(m,n) = Ry(m,n) * Rx(m)
end do
Thus, I see no other possibility than having a temporary which stores first the
evaluated right-hand side before it assigns it to the left-hand side.
As noted by Mikael, if the compiler knows that the two variables cannot alias,
no temporary is generated. That's the case if one of the variables is neither a
target nor a pointer - or if both variables are nonpointers (also with target)
but not dummy arguments - or both are nonpointers (also with target and dummy
argument) but allocatable. (Cf. gcc/fortran/dependency.c's
gfc_check_dependency).
* * *
It would help a lot if the temporary generation (malloc/free) could be moved
out of the loop; however, that's nontrivial to do for both the front end and
for the middle end. Cf. PR 19831 and PR 21046.
* * *
Regarding the heap usage: Since GCC 4.7 the flag -fstack-arrays exists (implied
by -Ofast), which uses the stack instead of the heap for the temporary array.
Thus, unless someone has a better idea or comes up with an optimizable test
case, I vote for closing this PR.
