[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)
--- 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: [EMAIL PROTECTED] 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=gccr1=1.425r2=1.426 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5478r2=1.5479 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.c.diff?cvsroot=gccr1=1.30r2=1.31 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/where_7.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/where_8.f90.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/forall_3.f90.diff?cvsroot=gccr1=1.3r2=1.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080
[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)
--- 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: [EMAIL PROTECTED] 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=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.180r2=1.5084.2.181 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.335.2.49r2=1.335.2.50 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-stmt.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.24.6.3r2=1.24.6.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/where_7.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/where_8.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/forall_3.f90.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3r2=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)
--- 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
[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)
--- 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)
--- 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)
--- 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)
--- 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)
--- 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)
--- 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)
--- 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)
--- 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)
--- 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)
--- 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)
--- 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)
--- 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)
--- 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 28forall (i=1:5,v(i)%valid) (gdb) l 23v(2)%p(:) = (/1, 2, 3, 4, 5, 6, 7, 8/) 24v(4)%p(:) = (/13, 14, 15, 16, 17, 18, 19, 20/) 25v(5)%p(:) = (/11, 12/) 26 27 28forall (i=1:5,v(i)%valid) 29 v(i)%p(1:v(i)%s) = v(6-i)%p(1:v(i)%s) 30end forall 31 32if (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)
--- 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
