Friedrich Hertweck wrote:
> This is the important point: the result is a NEW array with the
> desired shape; RESHAPE acts like an array constructor. It is NOT
> another view of the source array. In the general case the new array
> is quite different compared to the source.
I agree with this statement, but ...
> In this simple case (where the number and order of elements of the
> RESHAPE result is exactly that of the source) it is conceivable that
> an optimizing compiler might convey the address of the source to the
> function, provided the dummy argument is defined as
> integer, target, intent(in) :: R2(:,:)
> Because R2 cannot be modified, no harm could be done, could it?
> Well, I do not think this kind of optimization is permissible,
> because it changes the semantics of the program (like, for instance,
> -O3 with the IBM compiler, where sometimes a warning is issued to
> this effect). And it is easy to overrule the INTENT(IN) specification:
> just use RES2 to modify the array. It works on at least some systems!
I don't think I agree with you here. I don't see why the optimization could
not be done, as long as the dummy argument is intent(in). With intent(in) the
compiler can assume the argument will not be changed. If the user overrules it
as you suggest, then the program is not standard conforming.
But your main point stands intact. The result of reshape is an expression, which
will not exist after returning from the subroutine, and the pointer is in an
undefined state. It's another instance of something that might just happen to
work on some compilers, or some compilers at some optimization levels.
> - should a compiler be able to check on this situation?
> I should think yes, because all the information is there,
> because a module procedure has an explicit interface. The
> compiler could see that a pointer result of a function is
> associated directly with a target dummy argument which is
> an expression in the function invokation. This testing is
> similar to what the compiler has to do with INTENT arguments.
I think I disagree with this, too. From the explicit interface, the compiler
does not know that the result is associated with the dummy argument, i.e.,
it does not know about the statement res2=>r2
> The following program works on all of the eight systems mentioned
> above and does what was originally intended:
Very interesting. Sequence association is more liberal than I thought. I
thought that disagreement in rank was only allowed when the actual argument
is an array element, to be backward compatible with common practice in FORTRAN 77
programs, and that otherwise the mismatch was not standard conforming but happens
to work under most compilers when there is no explicit interface, because of the
way arguments are passed. 12.4.1.4 is worth a careful reading -- this legalizes
a lot of code I thought was illegal (in a loose sense of the word "legal").
> As already mentioned above, ptr(...) works on all of the eight systems
> I have access to. I would be interested to learn about any system
> where this simple mechanism does not work!
On Linux, your program works as expected with NAG, NASoftware, Absoft, Lahey,
Fujitsu, PGI and PSR.
--
William F. Mitchell
Mathematical and Computational Sciences Division
National Institute of Standards and Technology
[log in to unmask] http://math.nist.gov/~mitchell
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|