[Bug libfortran/95293] New: Fortran not passing array by reference

[Bug libfortran/95293] New: Fortran not passing array by reference

[david.sagan at gmail dot com]

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

            Bug ID: 95293
           Summary: Fortran not passing array by reference
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: david.sagan at gmail dot com
  Target Milestone: ---

The test program is:

program test
implicit none

type cb_struct
  real :: cbar = 0
end type

type scratch_struct
  type (cb_struct) :: cc(10)
  real :: zz(10) = 0
end type

type (scratch_struct), target :: s1

!

s1%cc(2)%cbar = 7
call sub2(s1%cc%cbar)
print *, 'Sub2 result:', s1%cc(2)%cbar, '  ! Wrong. Should be 10'

s1%zz(2) = 7
call sub3(s1%zz)
print *, 'Sub3 result:', s1%zz(2)

!--------------------------------------
contains

subroutine sub2(vec)
  real, target, intent(inout) :: vec(:)
  real, pointer :: ptr
  ptr => vec(1)
  print *, 'In sub2:', associated(ptr, s1%cc(1)%cbar), vec(2)
  vec(2) = 23
  s1%cc(2)%cbar = 10
end subroutine sub2

subroutine sub3(vec)
  real, target, intent(inout) :: vec(:)
  real, pointer :: ptr
  ptr => vec(1)
  print *, 'In sub3:', associated(ptr, s1%zz(1)), vec(2)
  vec(2) = 23
  s1%zz(2) = 10
end subroutine sub3

end program


Running gives:

> gfortran test.f90
> ./a.out 
 In sub2: F   7.00000000    
 Sub2 result:   23.0000000       ! Wrong. Should be 10
 In sub3: T   7.00000000    
 Sub3 result:   10.0000000

I get the same result on Linux and Mac with gcc 8.3.1 and gcc 9.3.

[Bug libfortran/95293] Fortran not passing array by reference

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to David Sagan from comment #0)
> The test program is:
> 
> program test
> implicit none
> 
> type cb_struct
>   real :: cbar = 0
> end type
> 
> type scratch_struct
>   type (cb_struct) :: cc(10)
>   real :: zz(10) = 0
> end type
> 
> type (scratch_struct), target :: s1
> 
> !
> 
> s1%cc(2)%cbar = 7
> call sub2(s1%cc%cbar)
> print *, 'Sub2 result:', s1%cc(2)%cbar, '  ! Wrong. Should be 10'
> 
> s1%zz(2) = 7
> call sub3(s1%zz)
> print *, 'Sub3 result:', s1%zz(2)
> 
> !--------------------------------------
> contains
> 
> subroutine sub2(vec)
>   real, target, intent(inout) :: vec(:)
>   real, pointer :: ptr
>   ptr => vec(1)
>   print *, 'In sub2:', associated(ptr, s1%cc(1)%cbar), vec(2)
>   vec(2) = 23
>   s1%cc(2)%cbar = 10
> end subroutine sub2
> 
> subroutine sub3(vec)
>   real, target, intent(inout) :: vec(:)
>   real, pointer :: ptr
>   ptr => vec(1)
>   print *, 'In sub3:', associated(ptr, s1%zz(1)), vec(2)
>   vec(2) = 23
>   s1%zz(2) = 10
> end subroutine sub3
> 
> end program
> 
> 
> Running gives:
> 
> > gfortran test.f90
> > ./a.out 
>  In sub2: F   7.00000000    
>  Sub2 result:   23.0000000       ! Wrong. Should be 10
>  In sub3: T   7.00000000    
>  Sub3 result:   10.0000000
> 
> I get the same result on Linux and Mac with gcc 8.3.1 and gcc 9.3.

% gfcx -Warray-temporaries -o z b.f90

b.f90:18:10:

   18 | call sub2(s1%cc%cbar)
      |          1
Warning: Creating array temporary at (1) [-Warray-temporaries]

[Bug libfortran/95293] Fortran not passing array by reference

[david.sagan at gmail dot com]

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

--- Comment #2 from David Sagan <david.sagan at gmail dot com> ---
The gcc documentation says:

‘array-temps’
Warns at run time when for passing an actual argument a temporary array had to
be generated. The information generated by this warning is sometimes useful in
optimization, in order to avoid such temporaries.

But a temporary array does not have to be created in this example. The ifort
compiler does not do this.

[Bug libfortran/95293] Fortran not passing array by reference

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sat, May 23, 2020 at 10:43:23PM +0000, david.sagan at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
> 
> --- Comment #2 from David Sagan <david.sagan at gmail dot com> ---
> The gcc documentation says:
> 
> ‘array-temps’
> Warns at run time when for passing an actual argument a temporary array had to
> be generated. The information generated by this warning is sometimes useful in
> optimization, in order to avoid such temporaries.
> 
> But a temporary array does not have to be created in this example. The ifort
> compiler does not do this.
> 

I suspect your code is invalid, and so gfortran results are
correct.  Namely, you have

   call sub2(s1%cc%cbar)
...
   subroutine sub2(vec)
      real, target, intent(inout) :: vec(:)
...
      vec(2) = 23
      s1%cc(2)%cbar = 10
...
   end subroutine sub2

>From F2028

2 The name of the dummy argument may be different from the name,
  if any, of its effective argument.  The dummy argument name is
  the name by which the effective argument is known, and by which
  it may be accessed, in the referenced procedure.

The effective argument is s1%cc%cbar and the dummy argument is
vec.  Within sub2, you can access vec, which vec(2) = 23 does.
The 's1%cc(2)%cbar' cannot be accessed via host association.  
Fortran also does not specify calling semantics, so this

   call sub2(s1%cc%cbar)

becomes

   tmp = s1%cc%cbar
   call sub2(tmp)
   s1%cc%bar= tmp

which is essentially 

create temporary for s1%cc%cbar
temporary becomes vec(:)
set vec(2) = 23
set s1%cc(2)%cbar = 10  (which is a no-no as it is an effective argument)
return to main and copy vec into s1%cc%cbar (which overwrites the no-no)

Of course, I could be wrong.  Of course, changing an entity
via both an effective argument and host association is also
questionable.

[Bug libfortran/95293] Fortran not passing array by reference

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Time to dig out the F2018 standard...

15.5.2.4 Ordinary dummy variables

9 If the dummy argument has the TARGET attribute

That's fulfilled

does not have the VALUE attribute,

That's fulfilled.

and either the effective argument is simply contiguous

That's fulfilled.

or the dummy argument is scalar, assumed-rank, or assumed-shape, and does not
have the CONTIGUOUS attribute,

That is not relevant here.

and the effective argument has the TARGET attribute 

That I will have to look up; if a has the TARGET attribute,
does a%b have it as well?

but is not a coindexed
object or an array section with a vector subscript

That's fullfilled.

then

any pointers associated with the effective argument become associated with the
orresponding dummy argument on invocation of the procedure, and

Not relevant to your test case.

when execution of the procedure completes, any pointers that do not become
undefined (19.5.2.5) and are associated with the dummy argument remain
associated with the effective argument.

Hm, this indicates that your test case may be valid if the condition
abouve is met.  Have to look at the definition of the TARGET attribute next...

[Bug libfortran/95293] Fortran not passing array by reference

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, May 24, 2020 at 06:47:18AM +0000, tkoenig at gcc dot gnu.org wrote:
> 
> and the effective argument has the TARGET attribute 
> 
> That I will have to look up; if a has the TARGET attribute,
> does a%b have it as well?
>

You're looking for

  If an object has the TARGET attribute, then all of its nonpointer
  subobjects also have the TARGET attribute. 

I believe it does not matter.  The effective argument is s1%cc%cbar.
The subroutine sub2() accesses s1%cc(2)%cbar via host association.
I've quoted the relevant part of the standard that says an effective
should be accessed via the dummy argument.  You basically have an
aliasing problem where something is known by a dummy argument 
and by host association.  It's a rather questionable programming
idiom.

Consider,

program foo
   real x
   x = 42
   call bar(x)
   print *, x
   contains
     subroutine bar(a)
        real, intent(inout) :: a
        a = 12
        x = 0
     end subroutine bar
end program foo

Should this print 12 or 0?  When bar returns 'a' has a value of
12, should this value be transferred to 'x' before the print 
statement is executed?

[Bug libfortran/95293] Fortran not passing array by reference

[david.sagan at gmail dot com]

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

--- Comment #6 from David Sagan <david.sagan at gmail dot com> ---
> program foo
>    real x
>    x = 42
>    call bar(x)
>    print *, x
>    contains
>      subroutine bar(a)
>         real, intent(inout) :: a
>         a = 12
>         x = 0
>      end subroutine bar
> end program foo
> 
> Should this print 12 or 0?  When bar returns 'a' has a value of
> 12, should this value be transferred to 'x' before the print 
> statement is executed?

'a' is passed by reference. Therefore, when the statement 'x = 0' is executed,
the value of 'a' immediately changes to 0. So '0' will be printed.

[Bug libfortran/95293] Fortran not passing array by reference

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, May 24, 2020 at 02:45:32PM +0000, david.sagan at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
> 
> --- Comment #6 from David Sagan <david.sagan at gmail dot com> ---
> > program foo
> >    real x
> >    x = 42
> >    call bar(x)
> >    print *, x
> >    contains
> >      subroutine bar(a)
> >         real, intent(inout) :: a
> >         a = 12
> >         x = 0
> >      end subroutine bar
> > end program foo
> > 
> > Should this print 12 or 0?  When bar returns 'a' has a value of
> > 12, should this value be transferred to 'x' before the print 
> > statement is executed?
> 
> 'a' is passed by reference. Therefore, when the statement 'x = 0' is executed,
> the value of 'a' immediately changes to 0. So '0' will be printed.
> 

The code, like your original example, is invalid.  As this is
not a numbered constraint, a Fortran processor is not required
to tell a programmer that the program violated the standard.

15.5.2.13 Restrictions on entities associated with dummy arguments

While an entity is associated with a dummy argument, the following
restrictions hold.

(1) Does not apply
(2) Does not apply
(3) Action that affects the value of the entity or any subobject
    of it shall be taken only through the dummy argument unless
    (a) Does not apply
    (b) Does not apply
    (c) Does not apply
    (d) Does not apply

[Bug libfortran/95293] Fortran not passing array by reference

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-07-08

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Isn't it an aliasing problem?

[Bug libfortran/95293] Fortran not passing array by reference

[kargl at gcc dot gnu.org]

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

--- Comment #9 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #8)
> Isn't it an aliasing problem?

No.  It is not an aliasing problem.  It is an invalid
program giving a result that the programmer does not
expect.  This is not a numbered constraint, and may be
difficult to reliably detect, so the Fortran standard
does not require a Fortran processor to catch the 
error.

[Bug libfortran/95293] Fortran not passing array by reference

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Could this PR be closed as INVALID?

[Bug libfortran/95293] Fortran not passing array by reference

[tkoenig at gcc dot gnu.org]

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

--- Comment #11 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #10)
> Could this PR be closed as INVALID?

Yes, I think so.

[Bug libfortran/95293] Fortran not passing array by reference

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> > Could this PR be closed as INVALID?
>
> Yes, I think so.

So closing.