--- Comment #5 from burnus at gcc dot gnu dot org 2007-03-02 10:43 ---
> Tobias, do the cases given in PR31016 include the one above?
> If yes, this PR could be closed as dupe?!
Actually not. PR 31016 (and related PR 31014) are about cases where one
actually knows that the memory is co
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-03-02 09:57 ---
Tobias, do the cases given in PR31016 include the one above?
If yes, this PR could be closed as dupe?!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31009
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-03-01 19:41 ---
(In reply to comment #2)
> Since the finer details of fortran still elude me, is it possible at all that
> in a statement as "this = other" were both shall be arrays of compatible
> shape,
> either stride may not e
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-03-01 16:58 ---
Tobias, I wouldn't expect gfortran to use memcpy if the array is not
continuous, as in your example.
OTOH, my naive assumption is, that given "this = other", "this(:) = other(:)"
or even "this(a:b) = other(c:d)", i
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-01 16:33 ---
> I'd like to suggest to do the same for derived type components.
The point is not components or not, the point is: Known size at compile time or
not. (A different thing are arrays of derived types.)
The same tree wi
