From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by sourceware.org (Postfix) with ESMTPS id 948B33858D39; Wed, 28 Feb 2024 19:55:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 948B33858D39 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmx.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 948B33858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=212.227.17.21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709150118; cv=none; b=EJvjKS5e/QteAUUCAwjP+N2krizxIfTJGBSpHUtD/S9rFr96ygDKDiZHfu7NC7hbCQbxdwU+C5j0gmCQ/FH9X0cjkjxNnMDIe3SzRyg10tyDlYp+e2QQWeR5KFQtR2d7w4T+rxAKsYFIGmytMQJUYV/LWrvt7/1ym/pmb8WfBqY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709150118; c=relaxed/simple; bh=qBtVDuZejyVp+bc96lU53S0jkRAtA9w28NJ0hEspeDQ=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=KyXx6yRpDVq2KijA9w/IfHUZcFW/PcU0xv35u160IlusNzXFiKAMUH/t1IlThYBQWtn6PSQlQS+eMTjyZ5ZImkD/RMi8vi4euSdWLNKa1sBRm/D4NAomgjJ/HiUjeJTLTk2lpH8qm/fT+wNr9hQMU1hyw+7DLCt6J+8jjVg9MOY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1709150114; x=1709754914; i=anlauf@gmx.de; bh=qBtVDuZejyVp+bc96lU53S0jkRAtA9w28NJ0hEspeDQ=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=HWdXzZPKQOij1EdkW+P8CKRcdh/5SRPQWDdf7pQQm+Cm+7B+37GET0bFg2wUk8Oe LG1+aJYwDIHsxx97FdLXcKrGaAtE6MRHMFzZes+notF8kkFeB/xMjmBbfz61pTpXJ JbRYjZGWc8cK3mZzdWtsfNEQfYVMWGkHwd3vLvMw3WVa8/oX1M6QK0jIfGuz9NPCf BA0EtZmmwnjOVGz0jN9Vt93554PsNht3CkVl2RMkAYv2uiLUTcAWb4KdORJQEsEpj edxUWTlT3tna4ZKFYkqriAbTe12LQW/U9/oWAAhBVaycPECg9sMlNa22KI0hlRn17 5i9UWGsIg6lUB+EaXg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.178.29] ([79.232.148.14]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mwwdf-1qh8N035vH-00yMyU; Wed, 28 Feb 2024 20:55:13 +0100 Message-ID: Date: Wed, 28 Feb 2024 20:55:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Fortran - Error compiling PDT Type-bound Procedures [PR82943/86148/86268] To: Alexander Westbrooks Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran References: <5a4694d0-c610-4297-8255-77a15cda92c4@gmx.de> 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:IYNh9AtFuSkArPw/kX5uhi9x6yXE1Kl+G/+EjgE+hQuTji3AHtF 9c/1gRuElfXQKD9VedW/DwSaeWpnLGvnbHvIOdrsPrzJ6tI+QV6uhAm8yvaCpSoOWkCnnlD irW7DsdVg3IR4h1phbHUn+TL0n4aR6kPixRy4aVSD37qCR3KA4w4NthNToI2+MZKmBnat93 BPSlvMlJzl4SQXbIMCT/Q== UI-OutboundReport: notjunk:1;M01:P0:8IVFBkRHjN0=;vbP8ZRrX2thnQ6D88S/Pk6wUmI6 FYkrvhRGyJ+SpJ7sa8RiC8jViQ5w6NBXs77+/Em8dXCqNwN/t/9W1uTXKcZ+4YSP64byv32MT ZOgblmab+nIvb5KuVi1+LU9pSRHuOyLUtAEi0R8Oof+bpyzHHDl/zrGdhxA641Qdim9KJdiMP pZQ37003+tQXm1hd4cVutMFIopFVD/S0GZ9k357wsdagR4AEU+vxS0W/4FaFr4oSb58sgrE5W DL0zctAosYOiPsMGJoyCo28ctT0opcshaX4+OPeMvlFicrKbs1cse/D5jqclEepAElL7Ppm91 m1FLBpbm7miVqz3Y5G5dj9fx3Zs6Al7Kyb+L76qjLbNg5taQ6/w5ZouRfLEPjQ/hdWjyj+sKk DKsdEBK3dps4f6aIwDGSwv4k07SzhmhOOsFIL8uODkrxVi9IcqOCJ6EM/jsY57zemaP6JTEu9 Uu8CEGjMWFBrpmE4/LSbtgYwlCSQ9M6FAXpt2If2Pzya3NW81GiN5c0OKMEt4OZgk0wMYVjvf UI6sFz8qaQd2qqRSebWtMDGw6LAeLp6Q5vqor9MOFg4gEeHbLvDpxjJzVWOe/2SiVC9db5TVq VOfnUp9EM5ejpHnMspsUwlZWXSCp5k1dH/RnD7pB51j9w1jFN+ohAQey7a6TMT8VDWJ62ZW02 Ov64TOkFToQ9VI5R7wytKLuj10DfvCIAEQ+46HVTy/R4lE5TWiBSmg6DUHH72l++pA03HAYfI cChAUEZCyUbd6+II/4PdmRZ23AYfd5KIN82fcnboEmOUxRGrLL4gRLTRUC6Hqcj6ibsba+tPf GUDTSi9avPZh94BmOP3tCDfGj9ND6TlaaUfR7O6FN8NKk= X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,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: Hi Alex, this is now mostly correct, with the following exceptions: First, you should notice that the formatting of the commit message, when checked using "git gcc-verify", needs minor corrections. You will be guided how to fix this yourself. Second, testcase pdt_37.f03 has an undeclared dummy argument, which can be detected by adding "implicit none" (I usually use that whenever implicit typing is not wanted explicitly). I would get: pdt_37.f03:33:47: 33 | subroutine assumed_len_param_ptr(this, that) | 1 Error: Symbol 'that' at (1) has no IMPLICIT type; did you mean 'this'? I assume you want to uncomment the declaration of dummy 'that'. Third, I still see a - minor - indentation/tabbing/space issue here: diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc index 44f89f6afb4..852e0820e6a 100644 =2D-- a/gcc/fortran/resolve.cc +++ b/gcc/fortran/resolve.cc [...] + if ( resolve_bindings_derived->attr.pdt_template + && gfc_pdt_is_instance_of (resolve_bindings_derived, + CLASS_DATA (me_arg)->ts.u.derived) + && (me_arg->param_list !=3D NULL) + && (gfc_spec_list_type (me_arg->param_list, + CLASS_DATA(me_arg)->ts.u.derived) + !=3D SPEC_ASSUMED)) OK with the above fixed. Thanks for the patch! Harald On 2/28/24 07:24, Alexander Westbrooks wrote: > Harald, > > Jerry helped me figure out my editor settings so that I could fix > whitespace and formatting issues in my code. With my editor configured > correctly, I saw that my code was not conforming to coding standards > as I previously thought it was. I have fixed those things and updated > my patch. Thank you for your patience. > > Let me know if this is okay to push to the trunk. > > Thanks, > > Alexander Westbrooks > > On Sun, Feb 25, 2024 at 2:40=E2=80=AFPM Alexander Westbrooks > wrote: >> >> Harald, >> >> Thank you for reviewing my code. I've been doing research and debugging= to investigate the error thrown by Intel and NAG for the deferred paramet= er in the dummy variable declaration. I found where the problem was and ad= ded the fix as part of my patch. I've attached the patch as a file, which = also includes your feedback and suggested fixes. I've updated the test cas= e pdt_37.f03 to check for the POINTER or ALLOCATABLE error as you suggeste= d. >> >> All regression tests pass, including the new ones, after including the = fix for the POINTER or ALLOCATABLE error for CLASS declarations of PDTs wh= en deferred length parameters are used. This was tested on WSL 2, with Ubu= ntu 20.04 distro. >> >> Is this okay to push to the trunk? >> >> Thanks, >> >> Alexander Westbrooks >> >> >> On Sun, Feb 11, 2024 at 2:11=E2=80=AFPM Harald Anlauf w= rote: >>> >>> Hi Alex, >>> >>> I've been unable to apply your patch to my local trunk, likely due to >>> whitespace issues my newsreader handles differently from your site. >>> I see it inline instead of attached. >>> >>> A few general remarks: >>> >>> Please follow the general recommendation regarding style if possible, >>> see https://www.gnu.org/prep/standards/standards.html#Formatting >>> regarding formatting/whitespace use (5.1) and comments (5.2) >>> >>> Also, when an error message text spans multiple lines, please place th= e >>> whitespace at the end of a line, not at the beginning of the new one: >>> >>>> + if ( resolve_bindings_derived->attr.pdt_template && >>>> + !gfc_pdt_is_instance_of(resolve_bindings_derived, >>>> + CLASS_DATA(me_arg)->ts.u.derived)) >>>> + { >>>> + gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of= " >>>> + " the parametric derived-type %qs", me_arg->name, proc->name= , >>> >>> gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of= " >>> "the parametric derived-type %qs", me_arg->name, >>> proc->name, >>> >>>> + me_arg->name, &where, resolve_bindings_derived->name); >>>> + goto error; >>>> + } >>> >>> The following change is almost unreadable: the lnegthy comment is spli= t >>> over three parts and almost hides the code. Couldn't this be combined >>> into one comment before the function? >>> >>>> diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc >>>> index fddf68f8398..11f4bac0415 100644 >>>> --- a/gcc/fortran/symbol.cc >>>> +++ b/gcc/fortran/symbol.cc >>>> @@ -5172,6 +5172,35 @@ gfc_type_is_extension_of (gfc_symbol *t1, gfc_= symbol >>>> *t2) >>>> return gfc_compare_derived_types (t1, t2); >>>> } >>>> >>>> +/* Check if a parameterized derived type t2 is an instance of a PDT >>>> template t1 */ >>>> + >>>> +bool >>>> +gfc_pdt_is_instance_of(gfc_symbol *t1, gfc_symbol *t2) >>>> +{ >>>> + if ( !t1->attr.pdt_template || !t2->attr.pdt_type ) >>>> + return false; >>>> + >>>> + /* >>>> + in decl.cc, gfc_get_pdt_instance, a pdt instance is given a 3 >>>> character prefix "Pdt", followed >>>> + by an underscore list of the kind parameters, up to a maximum of= 8. >>>> + >>>> + So to check if a PDT Type corresponds to the template, extract t= he >>>> core derive_type name, >>>> + and then see if it is type compatible by name... >>>> + >>>> + For example: >>>> + >>>> + Pdtf_2_2 -> extract out the 'f' -> see if the derived type 'f' i= s >>>> compatible with symbol t1 >>>> + */ >>>> + >>>> + // Starting at index 3 of the string in order to skip past the 'Pd= t' >>>> prefix >>>> + // Also, here the length of the template name is used in order to = avoid >>>> the >>>> + // kind parameter suffixes that are placed at the end of PDT insta= nce >>>> names. >>>> + if ( !(strncmp(&(t2->name[3]), t1->name, strlen(t1->name)) =3D=3D = 0) ) >>>> + return false; >>>> + >>>> + return true; >>>> +} >>>> + >>>> >>>> /* Check if two typespecs are type compatible (F03:5.1.1.2): >>>> If ts1 is nonpolymorphic, ts2 must be the same type. >>> >>> The following testcase tests for errors. I tried Intel and NAG on it >>> after commenting the 'contains' section of the type desclaration. >>> Both complained about subroutine deferred_len_param, e.g. >>> >>> Intel: >>> A colon may only be used as a type parameter value in the declaration = of >>> an object that has the POINTER or ALLOCATABLE attribute. [THIS] >>> class(param_deriv_type(:)), intent(inout) :: this >>> >>> NAG: >>> Entity THIS of type PARAM_DERIV_TYPE(A=3D:) has a deferred length type >>> parameter but is not a data pointer or allocatable >>> >>> Do we detect this after your patch? If the answer is yes, >>> can we add another subroutine where we check for this error? >>> (the dg-error suggests we only expect assumed len type parameters.) >>> If no, maybe add a comment in the testcase that this subroutine >>> may need updating later. >>> >>>> diff --git a/gcc/testsuite/gfortran.dg/pdt_37.f03 >>>> b/gcc/testsuite/gfortran.dg/pdt_37.f03 >>>> new file mode 100644 >>>> index 00000000000..68d376fad25 >>>> --- /dev/null >>>> +++ b/gcc/testsuite/gfortran.dg/pdt_37.f03 >>>> @@ -0,0 +1,34 @@ >>>> +! { dg-do compile } >>>> +! >>>> +! Tests the fixes for PR82943. >>>> +! >>>> +! This test focuses on the errors produced by incorrect LEN paramete= rs for >>>> dummy >>>> +! arguments of PDT Typebound Procedures. >>>> +! >>>> +! Contributed by Alexander Westbrooks >>>> +! >>>> +module test_len_param >>>> + >>>> + type :: param_deriv_type(a) >>>> + integer, len :: a >>>> + contains >>>> + procedure :: assumed_len_param ! Good. No error exp= ected. >>>> + procedure :: deferred_len_param ! { dg-error "All LE= N type >>>> parameters of the passed dummy argument" } >>>> + procedure :: fixed_len_param ! { dg-error "All LE= N type >>>> parameters of the passed dummy argument" } >>>> + end type >>>> + >>>> +contains >>>> + subroutine assumed_len_param(this) >>>> + class(param_deriv_type(*)), intent(inout) :: this >>>> + end subroutine >>>> + >>>> + subroutine deferred_len_param(this) >>>> + class(param_deriv_type(:)), intent(inout) :: this >>>> + end subroutine >>>> + >>>> + subroutine fixed_len_param(this) >>>> + class(param_deriv_type(10)), intent(inout) :: this >>>> + end subroutine >>>> + >>>> +end module >>>> + >>>