From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by sourceware.org (Postfix) with ESMTPS id 61C953858D28; Tue, 27 Jun 2023 19:27:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 61C953858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1687894027; x=1688498827; i=anlauf@gmx.de; bh=n3gGI8iMBfkTgeLEpvYhUpkmkYBT9IQss1g2S/1m8sQ=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=rGrs0z0sKU+VzA5+qLlCUqqFq/1DK0QzugNgCP5vIYAtrrGEN1AGPhGTvC7dK8vJJkghKRF S/Z8CBEuFe7AI/AbSD36UqsISnvJTZdaJboJytXx4xgrck3PZrwT9Kg2qALWLWJHMozvHAway LKk/16beKuRbCqLwxkkXui//arGO2uAtj/Jis3VrkQJPTPhlKV9fX0zATde4L06ukZN/PL8Ox 1RUzXl0HC3sU6z8/jUChoLCqlUeiEkF1sYd1IJH6dC9/YsAjJVRq0kgsPHt8nIMCxWC52b52f +oykVdj3govNUfwJyCue/VFfZ22veFXE/DCtV+wefZsZ2Yi6bjYw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.178.29] ([93.207.80.120]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mf0BG-1pXzu50OHS-00gX5s; Tue, 27 Jun 2023 21:27:07 +0200 Message-ID: <152f9e8b-6998-e505-7875-14dc14268382@gmx.de> Date: Tue, 27 Jun 2023 21:27:06 +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] PR49213 - [OOP] gfortran rejects structure constructor expression To: Paul Richard Thomas Cc: "fortran@gcc.gnu.org" , gcc-patches Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran References: Content-Language: en-US From: Harald Anlauf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:1TUpIH2R+/AWvd/U04mxf+GHqIRqBJjFpn7vc7R2Y+OrsEzVhpS od+TCWWWeda1LyMwppjqO27lHd6lW9Gke3Ts+pRgkMH+Z7+xvN/0z1WVjyZLJ47AvFxFc+x CwM+VHwjQHWewiy7Sx+SE60yf87w5SzXu0KHvEosyyhCxaXMpuJuFokC2koCI7dbUK2aANV GkE3BR2OfjMf74Uf6i0Hw== UI-OutboundReport: notjunk:1;M01:P0:c0uuOKMElJk=;qyYz+omEQKlcmMoHfXDHG/NGPjM yN2rrORv6ySqHeY4jIbQS0bBnY84wdaSNcQ3gyj+zhgFcmNbu3PbGJx5mRjnAzszh7bPeCHA2 MPXogHfRqaJLkyzIEqt39D4W3XaPk0d+PiFc2HNyWFIpy2WFg7kUN9almFjq8LiAk5tkE5CL5 SY8anpNz8isrgpk4Ej3C9YKaiOIxtcVBnfbo1CuIr7s6oJeiqI/dFxj79dFrE/+FxNSogBzq9 JJHDB1Dd00+vJtVK2EXAjBBGHAGSvdiY2UwR6v8yFJfUoQMtUu4t2yMKK4tuaEqj5jbqrCrJ6 lt7MYEqBqUG5O8+SwXWjiwgaSckfJXY+FQXY10WbILSqnKbPuC8MkrNUz3ZTO1LyzdkUMvpDG 9NzYbYbMqwzx3vkF1Udv3cNrD5md50rR4Zt0BJWb9Wbnq+rCU6mVV0aPUATjNBdHP187yV7kK 0/GPwCs8BzhRuKvK2gJTQ1hjG5FNyn1Y2Y2uw9nXBR1iUwcav3nHR0vFjR4Y8F/wWfR8scqG0 0L8CoBrlHwfb0PIeMB+vOU+jU2e+BbE7NrEFwLEjYP+wZLiSt2nqzgUIt1ev0j1/RW7kCpYl4 eSgtcc8sfj4znSTlIk/d+CW2xmCfCUp81dk7s0L5yO0eDgsGuT5kkMgw74yTIaT4EEDx+afBk 6WcBNVx/zHmb1yVFZlcjCkh75oDKAs5Bo5mf1Ctt5RC1BRB6TdRzFCuBAh1dJSW/s/bEQ1e9u TXz1Mf9xuqi/lK/VKqfjlIc/O3HftrDgYu4kgKhlgnj457KftT7VvwXawhFp84RV6CBoqkdQD Nlkx7O8l/SkdNKPp7nssA7y9u1PMApKiEOHIbxlOsIJ6PzHtDNDjUS4OLJX6FsjlgU6W1dwTE mYXp/9NSHcWdiDNuLsmSf+G2zeJ7d8p8Jadoz8iMnsjbZ65hIQP5KYjX+tNG8OsyTQ322iFaE KgVM12Be9wczxrUyLbg2zOVb2lY= X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Paul, this is much better now. I have only a minor comment left: in the calculation of the size of a character string you are using an intermediate gfc_array_index_type, whereas I have learned to use gfc_charlen_type_node now, which seems like the natural type here. OK for trunk, and thanks for your patience! Harald On 6/27/23 12:30, Paul Richard Thomas via Gcc-patches wrote: > Hi Harald, > > Let's try again :-) > > OK for trunk? > > Regards > > Paul > > Fortran: Enable class expressions in structure constructors [PR49213] > > 2023-06-27 Paul Thomas > > gcc/fortran > PR fortran/49213 > * expr.cc (gfc_is_ptr_fcn): Remove reference to class_pointer. > * resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow > associate names with pointer function targets to be used in > variable definition context. > * trans-decl.cc (get_symbol_decl): Remove extraneous line. > * trans-expr.cc (alloc_scalar_allocatable_subcomponent): Obtain > size of intrinsic and character expressions. > (gfc_trans_subcomponent_assign): Expand assignment to class > components to include intrinsic and character expressions. > > gcc/testsuite/ > PR fortran/49213 > * gfortran.dg/pr49213.f90 : New test > > On Sat, 24 Jun 2023 at 20:50, Harald Anlauf wrote: >> >> Hi Paul! >> >> On 6/24/23 15:18, Paul Richard Thomas via Gcc-patches wrote: >>> I have included the adjustment to 'gfc_is_ptr_fcn' and eliminating the >>> extra blank line, introduced by my last patch. I played safe and went >>> exclusively for class functions with attr.class_pointer set on the >>> grounds that these have had all the accoutrements checked and built >>> (ie. class_ok). I am still not sure if this is necessary or not. >> >> maybe it is my fault, but I find the version in the patch confusing: >> >> @@ -816,7 +816,7 @@ bool >> gfc_is_ptr_fcn (gfc_expr *e) >> { >> return e !=3D NULL && e->expr_type =3D=3D EXPR_FUNCTION >> - && (gfc_expr_attr (e).pointer >> + && ((e->ts.type !=3D BT_CLASS && gfc_expr_attr (e).pointe= r) >> || (e->ts.type =3D=3D BT_CLASS >> && CLASS_DATA (e)->attr.class_pointer)); >> } >> >> The caller 'gfc_is_ptr_fcn' has e->expr_type =3D=3D EXPR_FUNCTION, so >> gfc_expr_attr (e) boils down to: >> >> if (e->value.function.esym && e->value.function.esym->result) >> { >> gfc_symbol *sym =3D e->value.function.esym->result; >> attr =3D sym->attr; >> if (sym->ts.type =3D=3D BT_CLASS && sym->attr.class_ok) >> { >> attr.dimension =3D CLASS_DATA (sym)->attr.dimension; >> attr.pointer =3D CLASS_DATA (sym)->attr.class_pointer; >> attr.allocatable =3D CLASS_DATA (sym)->attr.allocatable; >> } >> } >> ... >> else if (e->symtree) >> attr =3D gfc_variable_attr (e, NULL); >> >> So I thought this should already do what you want if you do >> >> gfc_is_ptr_fcn (gfc_expr *e) >> { >> return e !=3D NULL && e->expr_type =3D=3D EXPR_FUNCTION && gfc_expr= _attr >> (e).pointer; >> } >> >> or what am I missing? The additional checks in gfc_expr_attr are >> there to avoid ICEs in case CLASS_DATA (sym) has issues, and we all >> know Gerhard who showed that he is an expert in exploiting this. >> >> To sum up, I'd prefer to use the safer form if it works. If it >> doesn't, I would expect a latent issue. >> >> The rest of the code looked good to me, but I was suspicious about >> the handling of CHARACTER. >> >> Nasty as I am, I modified the testcase to use character(kind=3D4) >> instead of kind=3D1 (see attached). This either fails here (stop 10), >> or if I activate the marked line >> >> ! cont =3D tContainer('hello!') ! ### ICE! ### >> >> I get an ICE. >> >> Can you have another look? >> >> Thanks, >> Harald >> >>> >> >>> OK for trunk? >>> >>> Paul >>> >>> Fortran: Enable class expressions in structure constructors [PR49213] >>> >>> 2023-06-24 Paul Thomas >>> >>> gcc/fortran >>> PR fortran/49213 >>> * expr.cc (gfc_is_ptr_fcn): Guard pointer attribute to exclude >>> class expressions. >>> * resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow >>> associate names with pointer function targets to be used in >>> variable definition context. >>> * trans-decl.cc (get_symbol_decl): Remove extraneous line. >>> * trans-expr.cc (alloc_scalar_allocatable_subcomponent): Obtain >>> size of intrinsic and character expressions. >>> (gfc_trans_subcomponent_assign): Expand assignment to class >>> components to include intrinsic and character expressions. >>> >>> gcc/testsuite/ >>> PR fortran/49213 >>> * gfortran.dg/pr49213.f90 : New test > > > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 8734738582A1 for ; Tue, 27 Jun 2023 19:27:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8734738582A1 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qEELI-0005mi-LZ for gcc-patches@gcc.gnu.org; Tue, 27 Jun 2023 21:27:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Harald Anlauf Subject: Re: [Patch, fortran] PR49213 - [OOP] gfortran rejects structure constructor expression Date: Tue, 27 Jun 2023 21:27:06 +0200 Message-ID: <152f9e8b-6998-e505-7875-14dc14268382@gmx.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Content-Language: en-US In-Reply-To: Cc: fortran@gcc.gnu.org X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Message-ID: <20230627192706.oUE9u0hQmTTxdB0UwzHyTTM1XVKO13xFaaqV_WnZuw0@z> Hi Paul, this is much better now. I have only a minor comment left: in the calculation of the size of a character string you are using an intermediate gfc_array_index_type, whereas I have learned to use gfc_charlen_type_node now, which seems like the natural type here. OK for trunk, and thanks for your patience! Harald On 6/27/23 12:30, Paul Richard Thomas via Gcc-patches wrote: > Hi Harald, > > Let's try again :-) > > OK for trunk? > > Regards > > Paul > > Fortran: Enable class expressions in structure constructors [PR49213] > > 2023-06-27 Paul Thomas > > gcc/fortran > PR fortran/49213 > * expr.cc (gfc_is_ptr_fcn): Remove reference to class_pointer. > * resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow > associate names with pointer function targets to be used in > variable definition context. > * trans-decl.cc (get_symbol_decl): Remove extraneous line. > * trans-expr.cc (alloc_scalar_allocatable_subcomponent): Obtain > size of intrinsic and character expressions. > (gfc_trans_subcomponent_assign): Expand assignment to class > components to include intrinsic and character expressions. > > gcc/testsuite/ > PR fortran/49213 > * gfortran.dg/pr49213.f90 : New test > > On Sat, 24 Jun 2023 at 20:50, Harald Anlauf wrote: >> >> Hi Paul! >> >> On 6/24/23 15:18, Paul Richard Thomas via Gcc-patches wrote: >>> I have included the adjustment to 'gfc_is_ptr_fcn' and eliminating the >>> extra blank line, introduced by my last patch. I played safe and went >>> exclusively for class functions with attr.class_pointer set on the >>> grounds that these have had all the accoutrements checked and built >>> (ie. class_ok). I am still not sure if this is necessary or not. >> >> maybe it is my fault, but I find the version in the patch confusing: >> >> @@ -816,7 +816,7 @@ bool >> gfc_is_ptr_fcn (gfc_expr *e) >> { >> return e != NULL && e->expr_type == EXPR_FUNCTION >> - && (gfc_expr_attr (e).pointer >> + && ((e->ts.type != BT_CLASS && gfc_expr_attr (e).pointer) >> || (e->ts.type == BT_CLASS >> && CLASS_DATA (e)->attr.class_pointer)); >> } >> >> The caller 'gfc_is_ptr_fcn' has e->expr_type == EXPR_FUNCTION, so >> gfc_expr_attr (e) boils down to: >> >> if (e->value.function.esym && e->value.function.esym->result) >> { >> gfc_symbol *sym = e->value.function.esym->result; >> attr = sym->attr; >> if (sym->ts.type == BT_CLASS && sym->attr.class_ok) >> { >> attr.dimension = CLASS_DATA (sym)->attr.dimension; >> attr.pointer = CLASS_DATA (sym)->attr.class_pointer; >> attr.allocatable = CLASS_DATA (sym)->attr.allocatable; >> } >> } >> ... >> else if (e->symtree) >> attr = gfc_variable_attr (e, NULL); >> >> So I thought this should already do what you want if you do >> >> gfc_is_ptr_fcn (gfc_expr *e) >> { >> return e != NULL && e->expr_type == EXPR_FUNCTION && gfc_expr_attr >> (e).pointer; >> } >> >> or what am I missing? The additional checks in gfc_expr_attr are >> there to avoid ICEs in case CLASS_DATA (sym) has issues, and we all >> know Gerhard who showed that he is an expert in exploiting this. >> >> To sum up, I'd prefer to use the safer form if it works. If it >> doesn't, I would expect a latent issue. >> >> The rest of the code looked good to me, but I was suspicious about >> the handling of CHARACTER. >> >> Nasty as I am, I modified the testcase to use character(kind=4) >> instead of kind=1 (see attached). This either fails here (stop 10), >> or if I activate the marked line >> >> ! cont = tContainer('hello!') ! ### ICE! ### >> >> I get an ICE. >> >> Can you have another look? >> >> Thanks, >> Harald >> >>> >> >>> OK for trunk? >>> >>> Paul >>> >>> Fortran: Enable class expressions in structure constructors [PR49213] >>> >>> 2023-06-24 Paul Thomas >>> >>> gcc/fortran >>> PR fortran/49213 >>> * expr.cc (gfc_is_ptr_fcn): Guard pointer attribute to exclude >>> class expressions. >>> * resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow >>> associate names with pointer function targets to be used in >>> variable definition context. >>> * trans-decl.cc (get_symbol_decl): Remove extraneous line. >>> * trans-expr.cc (alloc_scalar_allocatable_subcomponent): Obtain >>> size of intrinsic and character expressions. >>> (gfc_trans_subcomponent_assign): Expand assignment to class >>> components to include intrinsic and character expressions. >>> >>> gcc/testsuite/ >>> PR fortran/49213 >>> * gfortran.dg/pr49213.f90 : New test > > >