http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42118
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-03-01
08:06:01 UTC ---
(In reply to comment #3)
> Also exist in the gcc4.7 trunk. Can we mark it a Regression?
Only if it worked better in some previous GCC version, which does not seem to
be the case.
Additionally, as written before (comment 2), a reasonably well written DO loop
should be always as fast or faster than a FORALL. The definition of FORALL does
not allow for a good optimization in the general case. You should also consider
using Fortran 2008's DO CONCURRENT, which allows for more optimizations than a
normal DO loop. (Though, currently gfortran handles DO CONCURRENT as a normal
DO loop.)
As FORALL is rather complicated and not widely used, some possible
optimizations aren't implemented. (I have not checked whether that's the case
for the program in question.)
I did a quick run with six compilers. Result: The FORALL construct was between
3.2 to 5.25 times slower than the DO loop. Thus, other compilers do not handle
it better, either.
