Vectorizing HIRLAM 6: Honoring Fortran's Alias Requirements - might be a bug.

[Toon Moene]

L.S.,

This code:

      SUBROUTINE S(N)
      INTEGER N
      COMMON /COM/ A(100)
      REAL A
      REAL B(N), C(N), D(N)
      DO I = 1, N
         B(I) = D(I)
      ENDDO
      DO I = 1, N
         A(I) = B(I)
      ENDDO
      CALL S1(C(1))
      END

when compiled thusly:

$ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect4.f

draws the following "not vectorized" message:

vecta.f:6: note: LOOP VECTORIZED.
vecta.f:9: note: not vectorized: can't determine dependence between (*b_15)[D.928_29] and com.a[D.928_29]
vecta.f:9: note: vectorized 1 loops in function.

This cannot be right.  According to the Fortran Standards that have been,
that are, and that will be, A (which resides in common) and B (which is
a local array) cannot have *any* storage in common.  They're disjoint - they
won't unite no matter what.

So where does the compiler lose this valuable information ?

This is a hunt for the more advance vector-sorcerer.  Note that removing
the (1) from the CALL in the last-but-one line makes the compiler
recall the ever important Fortran alias rules.

[ Sprinkle the above with :-) liberally ]

Kind regards,

-- 
Toon Moene - e-mail: toon@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/