From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-23.smtpout.orange.fr [80.12.242.23]) by sourceware.org (Postfix) with ESMTPS id 03E2C38CB05C for ; Fri, 7 Jul 2023 12:22:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 03E2C38CB05C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr Received: from [192.168.1.13] ([86.215.161.51]) by smtp.orange.fr with ESMTPA id HkSnqCtaMqrfbHkTOqoZdi; Fri, 07 Jul 2023 14:22:06 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1688732526; bh=DZlyOSKm5rS5vzhEepVhgZz8biAUjkFc/QBdyyM3npw=; h=Date:Subject:To:References:From:In-Reply-To; b=WS6VrLZMggcnEYRSMMzdWGdidgXboNjssMld9SwWI2l5ORBRjZYsyKI4FTd7zikW9 4fTtTh5m6S5iOCGVKxVS/iO+OSvMVRZL92/yXq9uZFV+AhS7vfUHaNWlBJWGC0/9fD JcdZk5zeMkbIHH+8dYshR8l6mQQ299BIhBxfYJ6Hz0gKs3zgGLK9UrpCupivseRcce 0//vbEz0u++oeFzIizBOdRG+IN76YHbbmo+qXT99T7PLTS2zKeuh5M9X771t3H/Kaa Xf0ZE6XZbeW6tQJPv7shfTqHZSqzrStZTVqBmGTxbPZg7dKcAZ7w4aswsV4b8On854 G/lCGofaOY5hA== X-ME-Helo: [192.168.1.13] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Fri, 07 Jul 2023 14:22:06 +0200 X-ME-IP: 86.215.161.51 Content-Type: multipart/mixed; boundary="------------GJ8MCr7mscKV1EEVlZgqEzsR" Message-ID: Date: Fri, 7 Jul 2023 14:21:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH] Fortran: fixes for procedures with ALLOCATABLE,INTENT(OUT) arguments [PR92178] To: Harald Anlauf , fortran , gcc-patches References: <5a5306ae-0db1-c7e2-e744-a3beced17636@orange.fr> <3adc2904-9876-74d6-2b5d-3cc1896866c3@gmx.de> <3e31cc66-b7ae-adb0-f1a8-18b8bcc11c46@orange.fr> Content-Language: fr From: Mikael Morin In-Reply-To: X-Spam-Status: No, score=-9.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,JMQ_SPF_NEUTRAL,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This is a multi-part message in MIME format. --------------GJ8MCr7mscKV1EEVlZgqEzsR Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Le 05/07/2023 à 22:36, Harald Anlauf a écrit : > Hi Mikael, > > Am 05.07.23 um 16:54 schrieb Mikael Morin: >> Here is an example, admittedly artificial.  Fails with the above change, >> but fails with master as well. >> >> program p >>    implicit none >>    type t >>      integer :: i >>    end type t >>    type u >>      class(t), allocatable :: ta(:) >>    end type u >>    type(u), allocatable, target :: c(:) >>    c = [u([t(1), t(3)]), u([t(4), t(9)])] >>    call bar (allocated (c(c(1)%ta(1)%i)%ta), c(c(1)%ta(1)%i)%ta, >> allocated (c(c(1)%ta(1)%i)%ta)) >>    if (allocated(c(1)%ta)) stop 11 >>    if (.not. allocated(c(2)%ta)) stop 12 >> contains >>    subroutine bar (alloc, x, alloc2) >>      logical :: alloc, alloc2 >>      class(t), allocatable, intent(out) :: x(:) >>      if (allocated (x)) stop 1 >>      if (.not. alloc)   stop 2 >>      if (.not. alloc2)  stop 3 >>    end subroutine bar >> end > > while it looks artificial, it is valid, and IMHO it is a beast... > > I've played around and added another argument gfc_se *convse to > gfc_conv_class_to_class in an attempt to implement what I thought > you suggested (to get the .pre/.post separately), but in the end > this did not lead to working code.  And the tree-dump for your > example above is beyond what I can grasp. > > I've noticed that my attempt does not properly handle the > parmse.post; at least this is what the above example shows: > there is a small part after the call to bar that should have > been executed before that call, which I attribute to .post. > But my attempts in moving that part regresses on a couple > of testcases with class and intent(out).  I am at a loss now. > All that I can see after the call is a reassignment of the original data and vptr pointers from the temporary class container. They seem at their right place there. But part of the expression seems to be evaluated again, instead of being picked up from parmse.expr. > I am attaching the latest version of my patch to give you or > Paul or others the opportunity to see what is wrong or add the > missing pieces. > I'm attaching what I have (lightly) tested so far, which doesn't work. It seems gfc_conv_class_to_class reevaluates part of the original expression, which is not correct after deallocation. Will have a look again tonight. Mikael --------------GJ8MCr7mscKV1EEVlZgqEzsR Content-Type: text/x-patch; charset=UTF-8; name="pr92178_tmp.diff" Content-Disposition: attachment; filename="pr92178_tmp.diff" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2djYy9mb3J0cmFuL3RyYW5zLWV4cHIuY2MgYi9nY2MvZm9ydHJhbi90 cmFucy1leHByLmNjCmluZGV4IGViZWYxYTM2NTc3Li41NDI0OWM5YzYxNSAxMDA2NDQKLS0t IGEvZ2NjL2ZvcnRyYW4vdHJhbnMtZXhwci5jYworKysgYi9nY2MvZm9ydHJhbi90cmFucy1l eHByLmNjCkBAIC02ODE5LDkgKzY4MTksMTMgQEAgZ2ZjX2NvbnZfcHJvY2VkdXJlX2NhbGwg KGdmY19zZSAqIHNlLCBnZmNfc3ltYm9sICogc3ltLAogCQkgIGRlZmVyX3RvX2RlYWxsb2Nf YmxrID0gdHJ1ZTsKIAkJfQogCisJICAgICAgZ2ZjX3NlIGNsYXNzX3NlID0gcGFybXNlOwor CSAgICAgIGdmY19pbml0X2Jsb2NrICgmY2xhc3Nfc2UucHJlKTsKKwkgICAgICBnZmNfaW5p dF9ibG9jayAoJmNsYXNzX3NlLnBvc3QpOworCiAJICAgICAgLyogVGhlIGNvbnZlcnNpb24g ZG9lcyBub3QgcmVwYWNrYWdlIHRoZSByZWZlcmVuY2UgdG8gYSBjbGFzcwogCSAgICAgICAg IGFycmF5IC0gX2RhdGEgZGVzY3JpcHRvci4gICovCi0JICAgICAgZ2ZjX2NvbnZfY2xhc3Nf dG9fY2xhc3MgKCZwYXJtc2UsIGUsIGZzeW0tPnRzLCBmYWxzZSwKKwkgICAgICBnZmNfY29u dl9jbGFzc190b19jbGFzcyAoJmNsYXNzX3NlLCBlLCBmc3ltLT50cywgZmFsc2UsCiAJCQkJ ICAgICBmc3ltLT5hdHRyLmludGVudCAhPSBJTlRFTlRfSU4KIAkJCQkgICAgICYmIChDTEFT U19EQVRBIChmc3ltKS0+YXR0ci5jbGFzc19wb2ludGVyCiAJCQkJCSB8fCBDTEFTU19EQVRB IChmc3ltKS0+YXR0ci5hbGxvY2F0YWJsZSksCkBAIC02ODMxLDkgKzY4MzUsMTAgQEAgZ2Zj X2NvbnZfcHJvY2VkdXJlX2NhbGwgKGdmY19zZSAqIHNlLCBnZmNfc3ltYm9sICogc3ltLAog CQkJCSAgICAgQ0xBU1NfREFUQSAoZnN5bSktPmF0dHIuY2xhc3NfcG9pbnRlcgogCQkJCSAg ICAgfHwgQ0xBU1NfREFUQSAoZnN5bSktPmF0dHIuYWxsb2NhdGFibGUpOwogCi0JICAgICAg LyogRGVmZXIgcmVwYWNrYWdpbmcgYWZ0ZXIgZGVhbGxvY2F0aW9uLiAgKi8KLQkgICAgICBp ZiAoZGVmZXJfdG9fZGVhbGxvY19ibGspCi0JCWdmY19hZGRfYmxvY2tfdG9fYmxvY2sgKCZk ZWFsbG9jX2JsaywgJnBhcm1zZS5wcmUpOworCSAgICAgIHBhcm1zZS5leHByID0gY2xhc3Nf c2UuZXhwcjsKKwkgICAgICBzdG10YmxvY2tfdCAqY2xhc3NfcHJlX2Jsb2NrID0gZGVmZXJf dG9fZGVhbGxvY19ibGsgPyAmZGVhbGxvY19ibGsgOiAmcGFybXNlLnByZTsKKwkgICAgICBn ZmNfYWRkX2Jsb2NrX3RvX2Jsb2NrIChjbGFzc19wcmVfYmxvY2ssICZjbGFzc19zZS5wcmUp OworCSAgICAgIGdmY19hZGRfYmxvY2tfdG9fYmxvY2sgKCZwYXJtc2UucG9zdCwgJmNsYXNz X3NlLnBvc3QpOwogCSAgICB9CiAJICBlbHNlCiAJICAgIHsK --------------GJ8MCr7mscKV1EEVlZgqEzsR--