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