[Bug fortran/15080] New: [gfortran] Forall bounds not calculated correctly (forall_3.f90)

[Bug fortran/15080] New: [gfortran] Forall bounds not calculated correctly (forall_3.f90)

[pbrook at gcc dot gnu dot org]

We get things wrong when calculating the bounds of a forall statement. 
Expressions with pre trees end up in the wrong place. 
 
See http://gcc.gnu.org/ml/fortran/2004-02/msg00021.html

-- 
           Summary: [gfortran] Forall bounds not calculated correctly
                    (forall_3.f90)
           Product: gcc
           Version: tree-ssa
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P2
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pbrook at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] [gfortran] Forall bounds not calculated correctly (forall_3.f90)

[pbrook at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-04-22 21:24:47
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2004-12-27 17:22 -------
I get this output from the testsuite after upgrading to Fedora Core 3 (I assume
a new dejagnu version is responsible for this):

Running
/home/tobi/src/gcc/gcc-clean/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp
...
*** glibc detected *** free(): invalid next size (fast): 0x094d3268 ***
FAIL: gfortran.fortran-torture/execute/forall_3.f90 execution,  -O1

I'm not completely sure that the glibc error is issued during the execution of
this test, because it doesn't appear in the logs, but it seems likely, given
that it's the only test that fails.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-27 17:24 -------
This fails for me too on powerpc-darwin:
FAIL: gfortran.fortran-torture/execute/forall_3.f90 execution,  -O1


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2004-12-27 17:37 -------
I confirmed that glibc's error is indeed issued when running this testcase.
gdb's output:
(gdb) bt
#0  0x003f07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00138955 in raise () from /lib/tls/libc.so.6
#2  0x0013a319 in abort () from /lib/tls/libc.so.6
#3  0x0016bf9a in __libc_message () from /lib/tls/libc.so.6
#4  0x00172528 in _int_free () from /lib/tls/libc.so.6
#5  0x00172afa in free () from /lib/tls/libc.so.6
#6  0x00824762 in *_gfortrani_internal_free (mem=0x87e2278)
    at ../../../gcc-clean/libgfortran/runtime/memory.c:203
#7  0x08048a8d in MAIN__ () at forall_3.f90:28
#8  0x08048c73 in main (argc=0, argv=0x0)
    at ../../../gcc-clean/libgfortran/fmain.c:18
(gdb) frame 7
#7  0x08048a8d in MAIN__ () at forall_3.f90:28
28        forall (i=1:5,v(i)%valid)
(gdb) l
23        v(2)%p(:) = (/1, 2, 3, 4, 5, 6, 7, 8/)
24        v(4)%p(:) = (/13, 14, 15, 16, 17, 18, 19, 20/)
25        v(5)%p(:) = (/11, 12/)
26
27
28        forall (i=1:5,v(i)%valid)
29          v(i)%p(1:v(i)%s) = v(6-i)%p(1:v(i)%s)
30        end forall
31
32        if (any(v(1)%p(:) .ne. (/11, 10/))) call abort
(gdb)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[pbrook at gcc dot gnu dot org]

------- Additional Comments From pbrook at gcc dot gnu dot org  2004-12-27 17:41 -------
The test causes memory corruption, so the actual symptoms are fairly 
arbitrary. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2005-01-06 14:37 -------
*** Bug 18915 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl at lucon dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-08 22:28 -------
*** Bug 19339 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |danglin at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[amodra at bigpond dot net dot au]

------- Additional Comments From amodra at bigpond dot net dot au  2005-02-28 09:59 -------
Please disable forall_3.f90 until this bug is resolved.  It is rather
disconcerting to see a glibc malloc/free error message appearing when running
the testsuite.  Since it isn't immediately obvious that the error is emitted by
the compiled testcase, the person running the testsuite is left with a concern
that the memory corruption might be in the compiler itself.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-03-08 15:35 -------
Here's a somewhat reduced testcase that fails
for me on ia64-unknown-linux-gnu:

$ cat forall_5.f90
program evil_forall
  implicit none
  type t
    logical valid
    integer :: s
    integer, dimension(:), pointer :: p
  end type
  type (t), dimension (2) :: v
  integer i

  allocate (v(1)%p(2))
  allocate (v(2)%p(2))

  v(:)%valid = (/.true., .true./)
  v(:)%s = (/1, 2/)
  v(1)%p(:) = (/9, 10/)
  v(2)%p(:) = (/11, 12/)

  forall (i=1:2,v(i)%valid)
    v(i)%p(1:v(i)%s) = v(3-i)%p(1:v(i)%s)
  end forall

  if (any(v(1)%p(:) .ne. (/11, 10/))) call abort

end program

Still gives me 335 lines of *.t02.original - not easy to debug...

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[Thomas dot Koenig at online dot de]

------- Additional Comments From Thomas dot Koenig at online dot de  2005-03-08 20:30 -------
On i686-pc-linux-gnu, forall_5.f90 does the following:

$ gfortran forall_5.f90
$ ./a.out
Fortran runtime error: Attempt to allocate a negative amount of memory.
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0/configure --prefix=/home/ig25 --enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050306 (prerelease)

Did I mention I don't like memory corruption?

Thomas

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-04-29 12:17 -------
>From the *.t02.original dump, I'd say it is pretty much obvious what's wrong.
compute_inner_temp_size computes inner temporary size as:
D.905 = (int8) v[(int8) i.28 + -1].s;
but computes this before the 3 loops it then uses it in.
But that obviously depends on i.28 counter, which goes from 1 to 5 inclusive
in each of the loops.
But as D.905 assignment is evaluated before all of the 3 loops and not
inside of them as it IMHO should, it uses whatever value i.28 had before those
3 loops.  In the forall_3.f90 case there happens to be another loop before
that statement, so i.28 will be 6, so this will actually set
D.905 to (int8) v[(int8) 5].s, which is the first array element after the end
of the array.  It happens to be often 0 with -O2, which results in 0 bytes
being allocated for the temporary array, but it magically works with -O0,
because some fairly big number happens to be in that memory location.

    i.28 = 1;
    count.31 = 5;
    while (1)
      {
        if (count.31 <= 0) goto L.7; else (void) 0;
        temp.29[mi.30] = v[(int8) i.28 + -1].valid;
        mi.30 = mi.30 + 1;
        i.28 = i.28 + 1;
        count.31 = count.31 - 1;
      }
    L.7:;
    count1.32 = 0;
    D.905 = (int8) v[(int8) i.28 + -1].s;
    num.34 = 0;
    i.28 = 1;
    count.35 = 5;
    while (1)
      {
        if (count.35 <= 0) goto L.8; else (void) 0;
        num.34 = num.34 + D.905;
        i.28 = i.28 + 1;
        count.35 = count.35 - 1;
      }
    L.8:;
    temp.36 = (int4[0:] *) _gfortran_internal_malloc64 (num.34 * 4);
    mi.30 = 0;
    i.28 = 1;
    count.38 = 5;
    while (1)
      {
        if (count.38 <= 0) goto L.10; else (void) 0;
        if (temp.29[mi.30])
          {
            {
              int8 D.913;
              int4[0:] * D.912;
              int8 D.911;
              int4[0:] * D.910;

              count2.33 = 0;
              D.910 = v[(int8) (6 - i.28) + -1].p.data;
              D.911 = v[(int8) (6 - i.28) + -1].p.offset;
              D.912 = v[(int8) i.28 + -1].p.data;
              D.913 = v[(int8) i.28 + -1].p.offset;
              {
                int8 D.915;
                int8 S.37;

                D.915 = v[(int8) (6 - i.28) + -1].p.dim[0].stride;
                S.37 = 1;
                while (1)
                  {
                    if (S.37 > (int8) v[(int8) i.28 + -1].s) goto L.9; else
(void) 0;
                    (*temp.36)[count1.32 + count2.33] = (*D.910)[NON_LVALUE_EXPR
<S.37> * D.915 + D.911];
                    count2.33 = count2.33 + 1;
                    S.37 = S.37 + 1;
                  }
                L.9:;
              }
              count1.32 = count1.32 + D.905;
            }
          }
        else
          {
            (void) 0;
          }
        i.28 = i.28 + 1;
        mi.30 = mi.30 + 1;
        count.38 = count.38 - 1;
      }
    L.10:;
    count1.32 = 0;
    mi.30 = 0;
    i.28 = 1;
    count.40 = 5;
    while (1)
      {
        if (count.40 <= 0) goto L.12; else (void) 0;
        if (temp.29[mi.30])
          {
            {
              int8 D.920;
              int4[0:] * D.919;

              count2.33 = 0;
              D.919 = v[(int8) i.28 + -1].p.data;
              D.920 = v[(int8) i.28 + -1].p.offset;
              {
                int8 D.922;
                int8 S.39;

                D.922 = v[(int8) i.28 + -1].p.dim[0].stride;
                S.39 = 1;
                while (1)
                  {
                    if (S.39 > (int8) v[(int8) i.28 + -1].s) goto L.11; else
(void) 0;
                    (*D.919)[NON_LVALUE_EXPR <S.39> * D.922 + D.920] =
(*temp.36)[count1.32 + count2.33];
                    count2.33 = count2.33 + 1;
                    S.39 = S.39 + 1;
                  }
                L.11:;
              }
              count1.32 = count1.32 + D.905;
            }
          }
        else
          {
            (void) 0;
          }
        i.28 = i.28 + 1;
        mi.30 = mi.30 + 1;
        count.40 = count.40 - 1;
      }
    L.12:;
    _gfortran_internal_free ((void *) temp.36);
  }

At least in this particular case, D.905 could be computed inside of the
first loop that uses it and not be computed in the subsequent loops at all
(simply use one counter that goes from 0 all the way up instead of using
two counters), but I'm not sure if that is possible for all FOREACH loops.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[jakub at gcc dot gnu dot org]

------- Additional Comments From jakub at gcc dot gnu dot org  2005-04-29 15:20 -------
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02960.html>

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[tobi at gcc dot gnu dot org]

------- Additional Comments From tobi at gcc dot gnu dot org  2005-05-09 12:05 -------
Are you going to review that patch, Paul?  I don't think anybody else is qualified.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tobi at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[aj at gcc dot gnu dot org]

------- Additional Comments From aj at gcc dot gnu dot org  2005-05-15 21:37 -------
Paul, could you review the patch, please?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pbrook at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[pbrook at gcc dot gnu dot org]

------- Additional Comments From pbrook at gcc dot gnu dot org  2005-05-15 21:42 -------
I already did.

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01246.html

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|pbrook at gcc dot gnu dot   |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-17 06:31 -------
Subject: Bug 15080

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	jakub@gcc.gnu.org	2005-05-17 06:31:51

Modified files:
	gcc/fortran    : ChangeLog 
	gcc/testsuite  : ChangeLog 
	gcc/fortran    : trans-stmt.c 
	gcc/testsuite/gfortran.fortran-torture/execute: forall_3.f90 
Added files:
	gcc/testsuite/gfortran.fortran-torture/execute: where_7.f90 
	                                                where_8.f90 

Log message:
	PR fortran/15080
	* trans-stmt.c (generate_loop_for_temp_to_lhs): Remove SIZE and COUNT2
	arguments.  If LSS is gfc_ss_terminator, increment COUNT1 by 1, instead
	of incrementing COUNT2 and using COUNT1+COUNT2 increment COUNT1 and use
	just that as index.
	(generate_loop_for_rhs_to_temp): Likewise.
	(compute_overall_iter_number): Add INNER_SIZE_BODY argument.
	It non-NULL, add it to body.
	(allocate_temp_for_forall_nest_1): New function, split from
	allocate_temp_for_forall_nest.
	(allocate_temp_for_forall_nest): Add INNER_SIZE_BODY argument,
	propagate it down to compute_overall_iter_number.  Use
	allocate_temp_for_forall_nest_1.
	(gfc_trans_assign_need_temp): Remove COUNT2.  Call
	compute_inner_temp_size into a new stmtblock_t.  Adjust calls to
	allocate_temp_for_forall_nest, generate_loop_for_rhs_to_temp
	and generate_loop_for_temp_to_lhs.
	(gfc_trans_pointer_assign_need_temp): Adjust calls to
	allocate_temp_for_forall_nest.
	(gfc_evaluate_where_mask): Call compute_inner_temp_size into a new
	stmtblock_t.  Call compute_overall_iter_number just once, then
	allocate_temp_for_forall_nest_1 twice with the same size.
	Initialize mask indexes if nested_forall_info != NULL.
	(gfc_trans_where_2): Initialize mask indexes before calling
	gfc_trans_nested_forall_loop.
	
	* gfortran.fortran-torture/execute/forall_3.f90: Remove comment
	about the test failing.
	* gfortran.fortran-torture/execute/where_7.f90: New test.
	* gfortran.fortran-torture/execute/where_8.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.425&r2=1.426
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5478&r2=1.5479
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.c.diff?cvsroot=gcc&r1=1.30&r2=1.31
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/where_7.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/where_8.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/forall_3.f90.diff?cvsroot=gcc&r1=1.3&r2=1.4



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-05-17 07:02 -------
Subject: Bug 15080

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	jakub@gcc.gnu.org	2005-05-17 07:02:18

Modified files:
	gcc/testsuite  : ChangeLog 
	gcc/fortran    : ChangeLog 
	gcc/fortran    : trans-stmt.c 
	gcc/testsuite/gfortran.fortran-torture/execute: forall_3.f90 
Added files:
	gcc/testsuite/gfortran.fortran-torture/execute: where_7.f90 
	                                                where_8.f90 

Log message:
	PR fortran/15080
	* trans-stmt.c (generate_loop_for_temp_to_lhs): Remove SIZE and COUNT2
	arguments.  If LSS is gfc_ss_terminator, increment COUNT1 by 1, instead
	of incrementing COUNT2 and using COUNT1+COUNT2 increment COUNT1 and use
	just that as index.
	(generate_loop_for_rhs_to_temp): Likewise.
	(compute_overall_iter_number): Add INNER_SIZE_BODY argument.
	It non-NULL, add it to body.
	(allocate_temp_for_forall_nest_1): New function, split from
	allocate_temp_for_forall_nest.
	(allocate_temp_for_forall_nest): Add INNER_SIZE_BODY argument,
	propagate it down to compute_overall_iter_number.  Use
	allocate_temp_for_forall_nest_1.
	(gfc_trans_assign_need_temp): Remove COUNT2.  Call
	compute_inner_temp_size into a new stmtblock_t.  Adjust calls to
	allocate_temp_for_forall_nest, generate_loop_for_rhs_to_temp
	and generate_loop_for_temp_to_lhs.
	(gfc_trans_pointer_assign_need_temp): Adjust calls to
	allocate_temp_for_forall_nest.
	(gfc_evaluate_where_mask): Call compute_inner_temp_size into a new
	stmtblock_t.  Call compute_overall_iter_number just once, then
	allocate_temp_for_forall_nest_1 twice with the same size.
	Initialize mask indexes if nested_forall_info != NULL.
	(gfc_trans_where_2): Initialize mask indexes before calling
	gfc_trans_nested_forall_loop.
	
	* gfortran.fortran-torture/execute/forall_3.f90: Remove comment
	about the test failing.
	* gfortran.fortran-torture/execute/where_7.f90: New test.
	* gfortran.fortran-torture/execute/where_8.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.180&r2=1.5084.2.181
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.49&r2=1.335.2.50
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.24.6.3&r2=1.24.6.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/where_7.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/where_8.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/forall_3.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3&r2=1.3.40.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080

[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-17 11:25 -------
Fixed in 4.0.1.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.0.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080