This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension
- From: "burnus at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 28 Jan 2008 18:09:22 -0000
- Subject: [Bug fortran/34945] LBOUND fails for array with KIND(complex) used in zero-sized dimension
- References: <bug-34945-15620@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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|0000-00-00 00:00:00 |2008-01-28 18:09:22
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34945