Quoting Jakub Jelinek <[EMAIL PROTECTED]>:
> On Tue, Nov 01, 2005 at 02:01:43PM +0100,
> [EMAIL PROTECTED] wrote:
> > [ Bringing this back to fortran@, taking the optimizer guys out of CC: ]
> >
> > Quoting Toon Moene:
> > > I still have to construct a bug report of something that confuses the
> pa
On Tue, Nov 01, 2005 at 02:01:43PM +0100, [EMAIL PROTECTED] wrote:
> [ Bringing this back to fortran@, taking the optimizer guys out of CC: ]
>
> Quoting Toon Moene:
> > I still have to construct a bug report of something that confuses the parser
> > and that basically looks like this:
> >
> >
[ Bringing this back to fortran@, taking the optimizer guys out of CC: ]
Quoting Toon Moene:
> I still have to construct a bug report of something that confuses the parser
> and that basically looks like this:
>
> IMPLICIT CHARACTER*8 (Y)
> CHARACTER*11 Y1, Y2, Y3
> ...
> YA =
> I just read your contribution to the 2005 gcc summit about gfortran
> and HIRLAM. The two PRs(18283 and 21034) you wrote about are now
> fixed. LOC is now available. That just leaves some of the extra
> functionality of FLUSH(IOSTAT?), does it not? Would it compile
> completely if I were to add
Toon,
I just read your contribution to the 2005 gcc summit about gfortran and
HIRLAM. The two PRs(18283 and 21034) you wrote about are now fixed.
LOC is now available. That just leaves some of the extra functionality
of FLUSH(IOSTAT?), does it not? Would it compile completely if I were
to
I wrote:
I'm now going to try to compile HIRLAM with 32 bit pointers.
And ... here are the results:
With 64-bit pointers: 2685 out of 9799 loops vectorized.
With 32-bit pointers: 3269 out of 8854 loops vectorized.
Why there are more loops in the 64-bit case is beyond my understanding -
Dorit wrote:
It looks like maybe a 64bit scalar-evolution issue - when I compile on
powerpc-linux with -m64, I also get the
"vect4.f:4: note: not consecutive access"
message.
This problem looks very similar to PR18403 which has been resolved a
while
> When compiling for 64bit, there is an extra cast:
> In the 64bit case however, the vectorizer dumps show that the
> access-function returned for the index to array b is much more
> compilcated
> - the dataref analyzer doesn't seem to be able to extract the
> evoluti
Dorit wrote:
It looks like maybe a 64bit scalar-evolution issue - when I compile on
powerpc-linux with -m64, I also get the
"vect4.f:4: note: not consecutive access"
message.
This problem looks very similar to PR18403 which has been resolved a
while
It looks like maybe a 64bit scalar-evolution issue - when I compile on
powerpc-linux with -m64, I also get the
"vect4.f:4: note: not consecutive access"
message.
This problem looks very similar to PR18403 which has been resolved a while
ago:
When compiling for 32bit, we get the following repre
This one gets vectorized for me, on powerpc-linux:
~/mainline_cvs/bin/gfortran -O3 -ftree-vectorize -maltivec
-ftree-vectorizer-verbose=4 -S hilaram4.f90
hilaram4.f90:4: note: Alignment of access forced using peeling.
hilaram4.f90:4: note: Vectorizing an un
This one gets vectorized for me, on powerpc-linux:
~/mainline_cvs/bin/gfortran -O3 -ftree-vectorize -maltivec
-ftree-vectorizer-verbose=4 -S hilaram4.f90
hilaram4.f90:4: note: Alignment of access forced using peeling.
hilaram4.f90:4: note: Vectorizing an unaligned access.
hilaram4.f90:4: note
L.S.,
This code:
SUBROUTINE S(N)
DIMENSION A(N), B(N)
READ*,ISTART,ISTOP,B
DO I = ISTART, ISTOP
A(I) = B(I)
ENDDO
PRINT*,A
END
when compiled thusly:
$ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -msse2 vect4.f
draws the fol
13 matches
Mail list logo
