From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40843 invoked by alias); 2 Mar 2019 01:18:17 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 40751 invoked by uid 89); 2 Mar 2019 01:18:16 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=wandering, escaping, C_PTR, c_int X-HELO: troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (HELO troutmask.apl.washington.edu) (128.95.76.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 02 Mar 2019 01:18:15 +0000 Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x221IDcd051548 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 1 Mar 2019 17:18:13 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x221IDJc051547; Fri, 1 Mar 2019 17:18:13 -0800 (PST) (envelope-from sgk) Date: Sat, 02 Mar 2019 01:18:00 -0000 From: Steve Kargl To: Thomas Koenig Cc: "fortran@gcc.gnu.org" , gcc-patches Subject: Re: [patch, fortran] Fix pointers not escaping via C_PTR Message-ID: <20190302011813.GA51417@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <5ae29f94-956a-9c0c-20d7-241cee370162@netcologne.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5ae29f94-956a-9c0c-20d7-241cee370162@netcologne.de> User-Agent: Mutt/1.11.2 (2019-01-07) X-SW-Source: 2019-03/txt/msg00072.txt.bz2 On Thu, Feb 28, 2019 at 09:14:48PM +0100, Thomas Koenig wrote: > > the attached patch fixes a wrong-code bug for gfortran where pointers > were not marked as escaping. A C_PTR can be stashed away and reused > later (at least as long as the variable it points to remains active). > > This is not a regression, but IMHO a bad wrong-code bug. The chances > of this patch introducing regressions are really, really low. > > Regression-tested. OK for trunk? > Is this a wrong code bug or a clever user wandering off into undefined behavior? > subroutine init() > use, intrinsic :: iso_c_binding > implicit none > integer(c_int), pointer :: a > allocate(a) > call save_cptr(c_loc(a)) > a = 100 > end subroutine init Of particular note, 'a' is an unsaved local variable. When init() returns, 'a' goes out-of-scope. Fortran normally deallocates an unsaved allocatable entity, but 'a' is an unsaved local variable with the pointer attribute. For lack of a better term, 'allocate(a)' allocates an anonymous target and associates the anonymous target with the pointer 'a'. save_ptr() caches the address of the anonymous target. When init() returns does the anonymous target get deallocated or does the program leak memory? In addition, when init() returns, what happens to the pointer association of 'a'? I think it becomes undefined, which means the anonymous memory is inaccessible at least by Fortran means as there are no pointers associated with the anonymous target. The Fortran standard does not what happens to leaked memory. In particular, the Fortran standard does not guarantee that leaked memory is not reaped by some garbage collection or that it must retain value 100. -- Steve