Re: [gfortran testsuite, committed] Re: gfortran.dg/forall_1.f90

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Jun 06, 2005 at 11:12:51AM -0700, Steve Kargl wrote:
> On Mon, Jun 06, 2005 at 08:00:41PM +0200, Tobias Schl?ter wrote:
> > Andreas Jaeger wrote:
> > >>Does this cure the problem?
> > > 
> > > 
> > > No, it does not for me,
> > 
> > I tried the testcase with ifc (Intel(R) Fortran Compiler for 32-bit
> > applications, Version 8.1    Build 20040803) and with Sun's f95 (f90: Sun
> > Fortran 95 8.0 Patch 115984-02 2004/11/03) both with and without optimization,
> > and it didn't fail.  I've reviewed the testcase, and I'm sure that it
> > shouldn't abort and doesn't invoke undefined behavior any longer.
> > 
> > Thus I believe the testcase exposes a pre-existing bug in gfortran.  What
> > should we do?  XFAIL the testcase and open a PR?
> > 
> 
> Yes, XFAIL the testcase and open a PR.  NAG's compiler also compiles
> the program and it executes without a problem.

FYI, the bug is in the
forall (i=1:15, j=1:10, a1(j)%k <= j)
   i2(i,j) = j + i*11
end forall

code.  The temp array of logical4 (logical4 temp.26[150]; in my case,
BTW, does it really have to be logical4, can't be some 8 bit type?)
is computed correctly (150x .true.), but when used to see
if i2(i,j) should be stored or not, it advances by 16 logical4s
each time instead of 15, so in the last round it accesses 10 words
after the end of the array.

I'm looking into it now...

	Jakub