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 > > >