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 >>>> + >>> 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 3F1133858C98 for ; Wed, 28 Feb 2024 19:55:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3F1133858C98 Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3F1133858C98 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=116.202.254.214 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709150126; cv=none; b=Uta5LPLBLveLN79eBs4p4FOMTXkM+yQlF3bEwrOFsW9SfuaG2VUWsXXNSS0xbbdikVvSlywHrwjyBxDhXXLar1PYGICDd0vAYppaJFFYcz7R30TI4T4F0j9gao5wAR1sThUJlPdn+SOZwcA8KEfoyhnOUbL33lcyFfdS0hllXGc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709150126; c=relaxed/simple; bh=uUfjNVK5s6O4Zc8crmJNMzp8C6PZh6T6miTWgqmQN+0=; h=To:From:Subject:Date:Message-ID:Mime-Version; b=rVqvp1YLR+s39pOdJmnr3Iw3GJnCNmDNNawpW1PVb00GDh93vSh25Zxg9VYYSDp9JyMxMs3J8xjgoSWmxG9rVrABz+APGSLYMfkiuBkThpmcd+OjOXm3yb5M40f5oblBnRTaP3NiLW2lg6oh+iZi/T2qs9hXq2Ktv1Dtmi+BCPg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rfQ1Q-0005sP-GZ for gcc-patches@gcc.gnu.org; Wed, 28 Feb 2024 20:55:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Harald Anlauf Subject: Re: [PATCH] Fortran - Error compiling PDT Type-bound Procedures [PR82943/86148/86268] Date: Wed, 28 Feb 2024 20:55:11 +0100 Message-ID: References: <5a4694d0-c610-4297-8255-77a15cda92c4@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla Thunderbird Content-Language: en-US In-Reply-To: Cc: fortran@gcc.gnu.org X-Spam-Status: No, score=-9.1 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,KAM_SHORT,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: Message-ID: <20240228195511.4FVl4RwA4rtpdpywFkMhBh734Qtm_CbbhvfB8uXWmtU@z> 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 --- 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 != NULL) + && (gfc_spec_list_type (me_arg->param_list, + CLASS_DATA(me_arg)->ts.u.derived) + != 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 PM 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 parameter in the dummy variable declaration. I found where the problem was and added 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 case pdt_37.f03 to check for the POINTER or ALLOCATABLE error as you suggested. >> >> All regression tests pass, including the new ones, after including the fix for the POINTER or ALLOCATABLE error for CLASS declarations of PDTs when deferred length parameters are used. This was tested on WSL 2, with Ubuntu 20.04 distro. >> >> Is this okay to push to the trunk? >> >> Thanks, >> >> Alexander Westbrooks >> >> >> On Sun, Feb 11, 2024 at 2:11 PM Harald Anlauf wrote: >>> >>> 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 the >>> 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 split >>> 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 the >>>> 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' is >>>> compatible with symbol t1 >>>> + */ >>>> + >>>> + // Starting at index 3 of the string in order to skip past the 'Pdt' >>>> 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 instance >>>> names. >>>> + if ( !(strncmp(&(t2->name[3]), t1->name, strlen(t1->name)) == 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=:) 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 parameters 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 expected. >>>> + procedure :: deferred_len_param ! { dg-error "All LEN type >>>> parameters of the passed dummy argument" } >>>> + procedure :: fixed_len_param ! { dg-error "All LEN 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 >>>> + >>>