For integer :: a(2) integer, volatile :: i i = 1 a(1:i) = a(1:2) end The message is misleading: At line 4 of file aa.f90 Fortran runtime error: Array bound mismatch, size mismatch for dimension 1 of array 'a' (0/1) ISSUE: The size should be "1/2" and not "0/1" (For a zero-sized array the output is even "-1").
*** Bug 36029 has been marked as a duplicate of this bug. ***
PR39872 is probably a duplicate of this PR.
The following patch seems to fix the PR (not fully tested yet): --- ../_gcc_clean/gcc/fortran/trans-array.c 2009-04-20 13:44:15.000000000 +0200 +++ gcc/fortran/trans-array.c 2009-04-26 23:24:12.000000000 +0200 @@ -3249,8 +3249,10 @@ gfc_conv_ss_startstride (gfc_loopinfo * } /* Check the section sizes match. */ - tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type, end, - info->start[n]); + tmp = fold_build2 (MINUS_EXPR, gfc_array_index_type, + gfc_index_one_node, info->start[n]); + tmp = fold_build2 (PLUS_EXPR, gfc_array_index_type, + end, tmp); tmp = fold_build2 (FLOOR_DIV_EXPR, gfc_array_index_type, tmp, info->stride[n]); tmp = fold_build2 (MAX_EXPR, gfc_array_index_type, tmp, One thing I don't understand is why "fold_convert (long_integer_type_node, size[n])" is magically updated. With the patch I get: [ibook-dhum] f90/bug% gfc -fcheck=all pr35732.f90 [ibook-dhum] f90/bug% a.out At line 4 of file pr35732.f90 Fortran runtime error: Array bound mismatch, size mismatch for dimension 1 of array 'a' (1/2) [ibook-dhum] f90/bug% gfc -fcheck=all pr39872.f90 [ibook-dhum] f90/bug% a.out At line 7 of file pr39872.f90 Fortran runtime error: Array bound mismatch, size mismatch for dimension 1 of array 'a' (4/5)
*** Bug 39872 has been marked as a duplicate of this bug. ***
The patch in comment #3 works only for a stride equal to one -> some failures in the test suite.
I think the right patch is: --- ../_gcc_clean/gcc/fortran/trans-array.c 2009-04-20 13:44:15.000000000 +0200 +++ gcc/fortran/trans-array.c 2009-04-27 09:38:58.000000000 +0200 @@ -3253,6 +3253,8 @@ gfc_conv_ss_startstride (gfc_loopinfo * info->start[n]); tmp = fold_build2 (FLOOR_DIV_EXPR, gfc_array_index_type, tmp, info->stride[n]); + tmp = fold_build2 (PLUS_EXPR, gfc_array_index_type, + gfc_index_one_node, tmp); tmp = fold_build2 (MAX_EXPR, gfc_array_index_type, tmp, build_int_cst (gfc_array_index_type, 0)); /* We remember the size of the first section, and check all the Is a comment really needed? I have manually tested the failures seen with the patch in comment #3 and they all pass now except gfortran.dg/bounds_check_14.f90 which gives [ibook-dhum] f90/bug% gfc -fbounds-check /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/bounds_check_14.f90 [ibook-dhum] f90/bug% a.out At line 21 of file /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/bounds_check_14.f90 Fortran runtime error: Array bound mismatch, size mismatch for dimension 1 of array 'xca' (1/0) Line 21 is xca(1:1) = xda(1:2:mf3) and I think the diagnostic is now correct (mf3==-3 or -1) and I don't understand how the test is supposed to work: if size(xda(1:2:mf3)) == 0, as checked by a later test, how can xca take the value -1? What ma I missing? Also I'd be interested by ideas about test cases for this PR.
Posted a full patch at http://gcc.gnu.org/ml/fortran/2009-04/msg00283.html.
Subject: Bug 35732 Author: jvdelisle Date: Mon May 25 03:07:00 2009 New Revision: 147842 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147842 Log: 2009-05-24 Jerry DeLisle <jvdelisle@gcc.gnu.org> Dominique Dhumieres PR fortran/35732 PR fortran/39872 * trans-array.c (gfc_conv_ss_startstride): Add one to index. * gfortran.dg/bounds_check_fail_3.f90: New test. * gfortran.dg/bounds_check_fail_4.f90: New test. * gfortran.dg/bounds_check_14.f90: Update test. * gfortran.dg/bound_4.f90: Update test. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_fail_3.f90 trunk/gcc/testsuite/gfortran.dg/bounds_check_fail_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bound_4.f90 trunk/gcc/testsuite/gfortran.dg/bounds_check_14.f90
Should not this PR be closed as FIXED?
Close as FIXED. Part is fixed in 4.4 (cf. PR 39872), part only on the 4.5 trunk, but for a diagnostic off-by-one bug backporting to 4.4 is not really worth.