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