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

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

[burnus at gcc dot gnu dot org]

I am not 100% sure whether this is a duplicate of any of the other
missed-optimization PRs; it may well be. Currently, gfortran generates a
temporary for:

subroutine one()
  REAL, ALLOCATABLE  :: kpts(:,:)
  REAL, POINTER      :: syp(:,:)
  kpts = syp
end subroutine one

However, "kpts" cannot alias as it is neither a POINTER nor a TARGET; if there
are components, one needs to be more careful - one also needs to check for
POINTER in the ultra most component. (By the way, dependency.c's
check_data_pointer_types needs to be modified to fix this.)


-- 
           Summary: Unnecessary array temporary - non-pointer/non-target
                    does not alias
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


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

[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|0000-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

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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