With compiler gcc version 4.3.0 20080109 (experimental) [trunk revision 131426] (GCC) I get the following error message >gfortran vf0009.f vf0009.f: In function 'vf0009': vf0009.f:11: error: size of variable 'test_array' is too large If I replace the second line in the declaration of test_array with any of $ KIND(IDA1):5, $ KIND(YDA):9, $ 8:5, the program compiles without an error message. The LBOUND function is needed to trigger the error message Dick Hendrickson SUBROUTINE VF0009(IDA1,IDA2,YDA,HDA) INTEGER(4) IDA1(4) INTEGER(4) IDA2(4) COMPLEX(8) YDA(2) INTEGER(4) HDA(3) ! I N I T I A L I Z A T I O N S E C T I O N COMPLEX(KIND=4) :: TEST_ARRAY $( 4:5, $ KIND(YDA):5, $ 4:5, $ 4:5 ) ! T E S T S T A T E M E N T S IDA1(1:4) = LBOUND(TEST_ARRAY) END SUBROUTINE
I think the size is simply calculated as: ubound[n] + 1 - lbound[n]; which means: 5+1-8 = -2 At some point the variable is regarded as unsigned which means (for 8 byte variables): 18446744073709551614, which is not unexpected to be too large. (I'm ignoring here the byte-size of complex(4) and the other dimensions). The actual size is of cause "0" as the shape is 2 0 2 2. I think we have several places where a zero-sized array makes problems (cf. e.g. PR34980 for SHAPE). For this PR one probably needs to fix gfc_trans_create_temp_array, where "size" is calculated as follows: size = 1; for (n = 0; n < rank; n++) { stride[n] = size delta = ubound[n] + 1 - lbound[n]; size = size * delta; } size = size * sizeof(element); But maybe also something else.
(In reply to comment #1) Note the comment in trans-expr.c(gfc_map_intrinsic_function) : case GFC_ISYM_LBOUND: case GFC_ISYM_UBOUND: /* TODO These implementations of lbound and ubound do not limit if the size < 0, according to F95's 13.14.53 and 13.14.113. */ We need an intrinsic function that translates to cond ? a : b to do the right thing here. I could not see how to do it with existing front-endery. Paul
> Note the comment in trans-expr.c(gfc_map_intrinsic_function) : > case GFC_ISYM_LBOUND: > case GFC_ISYM_UBOUND: > /* TODO These implementations of lbound and ubound do not limit if > the size < 0, according to F95's 13.14.53 and 13.14.113. */ I had the impression that the problem is the array itself and not only ubound/lbound. You can replace LBOUND(TEST_ARRAY) by "print *, TEST_ARRAY", "SIZE(TEST_ARRAY)" etc. You will always get the middle end error: a.f:11: error: size of variable ‘test_array’ is too large (gcc/varasm.c:2095). What I find puzzling is the following: implicit none integer :: i(kind(4):1) integer :: j(4:1) print *, i(4:3) print *, j(4:3) end "j" works but "i" gives the same error message. If the size is not known at compile time (e.g. an automatic array) it seems to work. Actually, replacing "j(4:1)" by "j((4):1)" is enough to make it fail. I think "4:1" is replaced by "1:0" while "(4):1" is replaced by "4:1".
Reply to comment two: There is front-endery code to do "cond ? a : b" in the handling of missing optional dummy arguments. You can borrow from that.
(In reply to comment #4) > Reply to comment two: > > There is front-endery code to do "cond ? a : b" in the handling of missing > optional dummy arguments. You can borrow from that. > I know about the TREE_SSA expressions - what I need is a frontend, ie. a gfc_expr that delivers this functionality. The bit of code that needs sorting is manipulating gfc_expressions. The reason that this is necessary, is that the conditional operators carry over the magnitude of the conditional expression: i = 4 => (i > 0) * f => 4*f when implemented with gfc binops. In writing this, I realise that I never tried to convert the (i > 0) to logical but I do not think that it would make any difference. Paul
(In reply to comment #3) > I had the impression that the problem is the array itself and not only > ubound/lbound. Quite right, Tobias! Paul
Created attachment 15085 [details] Patch and testcase for this PR This one is regtesting right now. Cheers Paul
Test suite run without new regression on ppc/intel-darwin9, 32 and 64 bit modes, with the patch in http://gcc.gnu.org/ml/fortran/2008-02/msg00008.html. Thanks for the fix.
Subject: Bug 34945 Author: pault Date: Tue Feb 5 13:33:35 2008 New Revision: 132121 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132121 Log: 2008-02-05 Paul Thomas <pault@gcc.gnu.org> PR fortran/34945 * array.c (match_array_element_spec): Remove check for negative array size. (gfc_resolve_array_spec): Add check for negative size. 2008-02-05 Paul Thomas <pault@gcc.gnu.org> PR fortran/34945 * gfortran.dg/bounds_check_13.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_13.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog
Fixed on trunk - thanks, Dick! Paul