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

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Last reconfirmed|2010-02-25 12:42:15 |2021-12-17

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

[pault at gcc dot gnu dot org]

--- Comment #1 from pault at gcc dot gnu dot org  2010-02-25 12:42 ---
symbol.c:gfc_symbols_could_alias is the source of this extra temporary (called
by trans-array.c:gfc_could_be_alias and before that
gfc_conv_resolve_dependencies).

I am reading section 12.6 of Adams, Brainerd, Hendrickson, Maine, Martin and
Smith very carefully to understand what is defined and what is not in respect
of actual versus real arguments.

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

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-25 12:42:15
   date||


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

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

[burnus at gcc dot gnu dot 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