[Bug fortran/43172] Unnecessary array temporary - non-pointer/non-target does not alias

["burnus at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #2 from burnus at gcc dot gnu dot org  2010-02-25 13:21 -------
(In reply to comment #1)
> In principle,
> subroutine foo (ptr, tar)
>   real, target :: tar (:,:)
>   real, pointer :: ptr (:,:)
>   ptr => tar
> end subroutine
> 
> could cause troubles in 'one' in the testcase. If I read it correctly, this is
> undefined and so processor dependent.

Without studying the standard, I had assumes that your example is valid and
well-defined (of cause assuming that the proper actual arguments are used).

Actually, I do see no closer relation to my test case in comment 0 as there
neither kpts nor syp are dummy arguments and kpts is allocatable.

 * * *

> Thus, we could cure the PR very simply
> by fixing 'gfc_symbols_could_alias' but I think that it might be a good idea
> to warn of the undefined status of the actual argument corresponding to 'ptr'

Well, I think I now slowly start to understand your point. If one does
  real :: a(4,4)
  real,pointer :: p(:,:)
  call foo(p,a)
  a = 7
  p = 0
  if (a(1,1) == 0) stop 'Aliases'
the "processor" may optimize the "stop" line away since "a" has no target
attribute and is known to be 7.  This code is invalid just because accessing
the target of "p" is invalid as "p" is has undefined association status.

However, if one slightly extends the subroutine, even the code above is valid:
  subroutine foo (ptr, tar)
    [...]
    ptr => tar
    ptr = 8
    allocate(ptr(1,1))
  end subroutine

The problem is not much different from:
 subroutine foo(p)
   integer, pointer :: p
   integer, target :: t
   p => t

which is also perfectly valid - except that after the call the actual argument
associated with "p" is a pointer with "undefined" association state. I think in
both cases one can warn with -Wsurprising, but especially your case is still
valid if the actual argument has also the TARGET attribute.

Thus, I would probably only warn with -Wsurprising for dummy_ptr =>
local_target (i.e. "local_target" is not host/use associated nor a dummy
argument) - but warning for dummy arguments is also fine with me.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43172