[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension
--- Comment #10 from pault at gcc dot gnu dot org 2008-02-05 13:37 --- Fixed on trunk - thanks, Dick! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34945
[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension
--- Comment #9 from pault at gcc dot gnu dot org 2008-02-05 13:34 --- 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34945
[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension
--- Comment #8 from dominiq at lps dot ens dot fr 2008-02-03 22:46 --- 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/msg8.html. Thanks for the fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34945
[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension
--- Comment #7 from pault at gcc dot gnu dot org 2008-02-03 14:05 --- Created an attachment (id=15085) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15085&action=view) Patch and testcase for this PR This one is regtesting right now. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34945
[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension
--- Comment #6 from pault at gcc dot gnu dot org 2008-02-03 12:55 --- (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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34945
[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-31 08:30 --- (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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34945
[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-01-30 05:18 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34945
[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-29 13:22 --- > 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". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34945
[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension
--- Comment #2 from pault at gcc dot gnu dot org 2008-01-29 11:24 --- (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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34945
[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-28 18:09 ---
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.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||rejects-valid
Last reconfirmed|-00-00 00:00:00 |2008-01-28 18:09:22
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34945
