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 #7 from Tobias Burnus <burnus at gcc dot gnu.org> --- (In reply to Harald Anlauf from comment #5) > Do not forget that there are constraints for FORALL statements that are > not required for DO loops so that all assignments are independent. > This guarantees vectorization Not quite: The Fortran standard requires that the RHS is evaluated before the assignment to the LHS is done. This might even imply the generation of a temporary variable. By contrast, DO CONCURRENT is much better: The user guarantees that the is no order dependence, while constraints ensure that the many violations of this are detected at compile time. In addition, DO CONCURRENT permits more things within its body. By the way, the Fortran committee is considering to deprecate FORALL in the next standard (Fortran 2015) because it considers FORALL superior in nearly all aspects. For DO CONCURRENT, I have a pending patch which sets the vectorization safelen to infinity (well INT_MAX). I wonder whether one could do likewise for FORALL; that probably needs some dependency fine tuning to ensure that there is dependency at all between the LHS and RHS. To avoid temporaries, it is sufficient to be either forward or backward dependency free. (Setting the safelen for whole-array operations probably also makes sense. There, the same applies.) (In reply to Lionel GUEZ from comment #6) > There is also the problem of the order of indices in a forall. I guess this > is in close relation to the comparison of do and forall. Try compiling with -floop-interchange (requires a GCC built with Graphite). Deciding which order is best is not a trivial task, although in simple cases as yours, it shouldn't be that difficult. Maybe someone finds the time to do it. [Presumably the same issue comes up with DO CONCURRENT, if one places multiple iteration variables into that statement (opposed to using multiple DO CONCURRENT statements with one iteration variable).] > According to the Fortran standard, the order of indices in the forall header > is of no consequence. Well, it doesn't with any of the compilers: The resulting value is always the same. The standard doesn't tell anything about the performance (not about the index walking order).