From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6421 invoked by alias); 18 Jun 2009 15:18:05 -0000 Received: (qmail 6324 invoked by uid 48); 18 Jun 2009 15:17:44 -0000 Date: Thu, 18 Jun 2009 15:18:00 -0000 Message-ID: <20090618151744.6323.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/40440] Automatic deallocation component of DT function return value In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "burnus at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-06/txt/msg01306.txt.bz2 ------- Comment #9 from burnus at gcc dot gnu dot org 2009-06-18 15:17 ------- (In reply to comment #7) > I'm still convinced that this is a problem of the compiler, since it works with the > NAG and Intel compilers. Well, compilers can have all bugs - and not all invalid programs can be diagnosed as such by a compiler. In any case, I believe gfortran has a bug (cf. comment 5 and comment 8). (In reply to comment #8) > Regarding the big program: [...] I think the big program is valid (at least with this regard) as the following applies. "If the dummy argument has the TARGET attribute, does not have the VALUE attribute, and is either a scalar or an assumed-shape array, and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript then (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure and (2) When execution of the procedure completes, any pointers that do not become undefined (16.4.2.1.3) and are associated with the dummy argument remain associated with the actual argument." [F2003, 12.4.1.2 Actual arguments associated with dummy data objects] And in "16.4.2.1.3 Events that cause the association status of pointers to become undefined". Relevant would be for instance: "(4) Execution of a RETURN or END statement causes the pointer’s target to become undefined (item (3) of 16.5.6)," which is never the case for the PROGRAM; additionally, the SAVE preserves it even longer [(3) in 16.5.6]: "Variables become undefined as follows: [...] (3) When execution of an instance of a subprogram completes, (a) its unsaved local variables become undefined," -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440