From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F19303864835; Fri, 25 Jun 2021 13:33:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F19303864835 From: "ygalklein at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/101199] program changes the value of a dummy argument Date: Fri, 25 Jun 2021 13:33:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 11.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ygalklein at gmail dot com 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2021 13:33:08 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101199 --- Comment #4 from ygal klein --- (In reply to J=C3=BCrgen Reuter from comment #3) > I think that indeed this is not something the compiler needs to do as > expected, as it is an aliasing problem.=20 > In the advance TBP you are calling again the init routine. The init > routines sets the value of this%var1 to the argument with which it is > called. In this%advance you are calling the init routine with the > argument this%var1. However, in the init routine, the struct1 type > is intent(out), so it is not guaranteed that the value of struct1%var1 > is accessible when calling the init routine from an earlier initialization > of that type. That is the aliasing problem: advance calls > the init routine, the init routine creates a new instance of struct1 > and you are not guaranteed that you can access the struct1%var1 component. > There are several ways out: > (1) define this in the init routine as intent(inout), very unusual for > an initializer, but then gfortran does what you expect > (2) define a global instance of struct1 in the module, e.g. > type(original_struct), save, public :: struct_global > and in advance then call the (before initialized) > this%init(struct_global%var1) Thank you for the reply. After posting the bug report - I saw that implementing (inout) as your numb= er 1 suggestion - dodges the problem - though as you mentioned having inout for = this in an init routine is somewhat unnatural. The 2nd suggestion is something that I was trying to avoid in the first pla= ce - i.e copying a whole type (this minimal example is a small type - but origin= ally it is a type with a lot of instances and procedures) In fact - I could have had advance as a function that returns a type - but = then I would be paying the price of copyin assignment of a big type. Anyway - you conclude that gfortran is behaving as it should and that the f= act that ifort works - is somewhat a coincidence?=