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.

Reply via email to