------- 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