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
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.
This fails for me too on powerpc-darwin: FAIL: gfortran.fortran-torture/execute/forall_3.f90 execution, -O1
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)
The test causes memory corruption, so the actual symptoms are fairly arbitrary.
*** Bug 18915 has been marked as a duplicate of this bug. ***
*** Bug 19339 has been marked as a duplicate of this bug. ***
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.
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...
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
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.
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02960.html>
Are you going to review that patch, Paul? I don't think anybody else is qualified.
Paul, could you review the patch, please?
I already did. http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01246.html
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
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
Fixed in 4.0.1.