http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52151
Tobias Burnus <burnus at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |burnus at gcc dot gnu.org |gnu.org | --- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-02-08 16:48:42 UTC --- Created attachment 26617 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26617 Draft patch Regarding my suggested patch from comment 0: The patch is not needed as one has: D.1897 = ((b.dim[0].lbound - D.1894.dim[0].lbound) - b.dim[0].ubound) + D.1894.dim[0].ubound != 0; If "b" is not allocated, doing this arithmetic does not make sense, but it is nevertheless valid. The only issue in which one can run is one overflows (for random/uninitialized data). While that's not a good thing to happen, it should not matter. (The only potential issue I could see is -ftrapv or something like that. However, my impression is that integer overflow trapping doesn't work at all.) * * * Better patch: Taking the stride from the LHS is not helpful, if it is not allocated or has the wrong bounds. Take it from the result variable instead. We do not have to take care of any stride in the Fortran sense as the LHS is allocatable (i.e. contiguous); hence, the only stride is due to the internal implementation and due to the shape. But that stride is already correct in the result variable. Additionally, it is useful to not only read the correct stride but also to set the stride ...