From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2848 invoked by alias); 27 Oct 2019 07:57:43 -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 2828 invoked by uid 89); 27 Oct 2019 07:57:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-lj1-f173.google.com Received: from mail-lj1-f173.google.com (HELO mail-lj1-f173.google.com) (209.85.208.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 27 Oct 2019 07:57:41 +0000 Received: by mail-lj1-f173.google.com with SMTP id y3so8072794ljj.6; Sun, 27 Oct 2019 00:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vliSdsW4nSlOQnM9LM7WVoBIDmzq2LP0RHwpoQ1L5DA=; b=XJ4CIX/trLAL3ybkkL9Tq3BM04MqYAwxxXLN9rptWbXCt3lW7+eh9tHzOV6koMUvcd r1TJo/WMbkKjJWvnkYNLoIada/yuSy9vl2jdxoOMndoREiLgk/zuDsPQ6adtN+WXMrpI CrDkEiQU4G4uhDFVq8cpBAGjdmCdOpJUntyEVW+Va2ykzinPorCog/eonStV7nUASPVz xf6g9E4q/MJrK+v9SsPZLGIr/TwzbacxkjTZeRjzlnvTWEIghuv/XQn25e0OTpUJh2Ii KJzENGjBqGT19tPYPvMiphuBJoYCthEALjlTBVrLOAWpjQmOf/6CjonuM+QFw9QNnnql WW7Q== MIME-Version: 1.0 References: <9dc15d5a-5f80-a5fa-67a0-9d633f0e6923@codesourcery.com> In-Reply-To: <9dc15d5a-5f80-a5fa-67a0-9d633f0e6923@codesourcery.com> From: Paul Richard Thomas Date: Sun, 27 Oct 2019 08:08:00 -0000 Message-ID: Subject: Re: [Patch, Fortran] PR91863 - fix call to bind(C) with array descriptor To: Tobias Burnus Cc: gcc-patches , fortran Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-10/txt/msg01914.txt.bz2 Hi Tobias, Thanks for taking care of this. OK for trunk and 9-branch. Cheers Paul On Wed, 23 Oct 2019 at 14:07, Tobias Burnus wrote: > > With the trunk, there are three issues: > > (a) With bind(C), the callee side handles deallocation with intent(out). > > This should produce the code: > if (cfi.0 != 0B) > { > __builtin_free (cfi.0); > cfi.0 = 0B; > } > This fails as cfi.0 (of type 'void*') is dereferenced and > *cfi.0 = 0B' (i.e. assignment of type 'void') causes the ICE. > > > (b) With that fixed, one gets: > sub (cfi.4); > _gfortran_cfi_desc_to_gfc_desc (&a, &cfi.4); > if (cfi.4 != 0B) > __builtin_free (cfi.4); > ... code using "a" ... > That also won't shine as 'a.data' == 'cfi.4'; hence, one > accesses already freed memory. > > I don't see whether freeing the cfi memory makes sense at all; > as I didn't come up with a reason, I removed it for good. > > > Those issues, I have solved. The third issue is now PR fortran/92189: > (c) When allocating memory in a Fortran-written Bind(C) function, the > shape/bounds changes are not propagated back to Fortran. > Namely, "sub" lacks some _gfortran_gfc_desc_to_cfi_desc call at the end! > > The issue pops up, if you change 'dg-do compile' into 'dg-do run'. For > using a C-written function, that's a non-issue. Hence, it makes sense > to fix (a)+(b) of the bug separately. > > > OK for the trunk and GCC 9? (At least the ICE is a regression.) > > Tobias > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein