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.
