From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 1CF8B3851C06; Sun, 24 May 2020 07:55:35 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1CF8B3851C06
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
 s=default; t=1590306935;
 bh=aOijpdWqfYa0o2vQ9JktVARsUs5U0Q490cctCpLIrr0=;
 h=From:To:Subject:Date:In-Reply-To:References:From;
 b=w/8pS87BiluiNLrpgQ9qtkwSIn7kqFaOevP3QagqiaUPTpGiw8ksMaQOPOXqZc709
 SCXEz5mquXkT63S1LwPgP/CcR+jEFIPPap9bs+AFqooq+HnxP9fv2O1wTd//ct58Ab
 XzsUXVaLzgcIiRAIMwxKvcIgKl8jJIRCefLZEZDA=
From: "sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/95293] Fortran not passing array by reference
Date: Sun, 24 May 2020 07:55:34 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-95293-4-v3GtsPQ15C@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-95293-4@http.gcc.gnu.org/bugzilla/>
References: <bug-95293-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Sun, 24 May 2020 07:55:35 -0000

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

--- 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:
>=20
> and the effective argument has the TARGET attribute=20
>=20
> 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.=20

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=20
and by host association.  It's a rather questionable programming
idiom.

Consider,

program foo
   real x
   x =3D 42
   call bar(x)
   print *, x
   contains
     subroutine bar(a)
        real, intent(inout) :: a
        a =3D 12
        x =3D 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=20
statement is executed?=