[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 Alexander Westbrooks changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #20 from Alexander Westbrooks --- Marking this as resolved/fixed
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 --- Comment #19 from Alexander Westbrooks --- I have pushed an approved patch to the trunk.
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 --- Comment #18 from GCC Commits --- The master branch has been updated by Alexander Westbrooks alexanderw : https://gcc.gnu.org/g:edfe198084338691d0facc86bf8dfa6ede3ca676 commit r14-9229-gedfe198084338691d0facc86bf8dfa6ede3ca676 Author: Alexander Westbrooks Date: Wed Feb 28 20:03:46 2024 -0600 Fortran - Error compiling PDT Type-bound Procedures [PR82943/86148/86268] This patch allows parameterized derived types to compile successfully when typebound procedures are specified in the type specification. Furthermore, it allows function calls for PDTs by setting the f2k_derived space of PDT instances to reference their original template, thereby giving it referential access to the typebound procedures of the template. Lastly, it adds a check for deferred length parameters of PDTs in CLASS declaration statements, and correctly throws an error if such declarations are missing POINTER or ALLOCATABLE attributes. 2024-02-25 Alexander Westbrooks gcc/fortran/ChangeLog: PR fortran/82943 PR fortran/86148 PR fortran/86268 * decl.cc (gfc_get_pdt_instance): Set the PDT instance field 'f2k_derived', if not set already, to point to the given PDT template 'f2k_derived' namespace in order to give the PDT instance referential access to the typebound procedures of the template. * gfortran.h (gfc_pdt_is_instance_of): Add prototype. * resolve.cc (resolve_typebound_procedure): If the derived type does not have the attribute 'pdt_template' set, compare the dummy argument to the 'resolve_bindings_derived' type like usual. If the derived type is a 'pdt_template', then check if the dummy argument is an instance of the PDT template. If the derived type is a PDT template, and the dummy argument is an instance of that template, but the dummy argument 'param_list' is not SPEC_ASSUMED, check if there are any LEN parameters in the dummy argument. If there are no LEN parameters, then this implies that there are only KIND parameters in the dummy argument. If there are LEN parameters, this would be an error, for all LEN parameters for the dummy argument MUST be assumed for typebound procedures of PDTs. (resolve_pdt): Add a check for ALLOCATABLE and POINTER attributes for SPEC_DEFERRED parameters of PDT class symbols. ALLOCATABLE and POINTER attributes for a PDT class symbol are stored in the 'class_pointer' and 'allocatable' attributes of the '_data' component respectively. * symbol.cc (gfc_pdt_is_instance_of): New function. gcc/testsuite/ChangeLog: PR fortran/82943 PR fortran/86148 PR fortran/86268 * gfortran.dg/pdt_4.f03: Update modified error message. * gfortran.dg/pdt_34.f03: New test. * gfortran.dg/pdt_35.f03: New test. * gfortran.dg/pdt_36.f03: New test. * gfortran.dg/pdt_37.f03: New test. Signed-off-by: Alexander Westbrooks
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 --- Comment #17 from Steve Kargl --- On Sat, Jan 20, 2024 at 09:37:17PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 > > --- Comment #16 from Jerry DeLisle --- > (In reply to Alexander Westbrooks from comment #15) > > Created attachment 57176 [details] > > Proposed Patch to fix PR82943, PR86148, PR86268 > > I am attempting to roll with this. Steve, do you know where the copyright > assignment forms are? I a,m hunting for them and I asked on the gcc IRC > channel > as well. > I beleive that FSF assignments are not public. It's been along since I dealt with someone getting an assignment. I recall asking someone on the GCC steering committee for confirmation. I haven't dealt with the DCO method.
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 --- Comment #16 from Jerry DeLisle --- (In reply to Alexander Westbrooks from comment #15) > Created attachment 57176 [details] > Proposed Patch to fix PR82943, PR86148, PR86268 I am attempting to roll with this. Steve, do you know where the copyright assignment forms are? I a,m hunting for them and I asked on the gcc IRC channel as well.
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 --- Comment #15 from Alexander Westbrooks --- Created attachment 57176 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57176=edit Proposed Patch to fix PR82943, PR86148, PR86268
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #14 from Jerry DeLisle --- (In reply to Alexander Westbrooks from comment #13) > I sent in the patch to those emails. Hopefully now the ball will start > rolling and I can slowly get this packaged into a legitimate fix. I'll post > updates here as I receive them. > > The patch is below, if you would like to try it. I did this in the GCC 14 > code. > I saw your email. Thanks for getting involved!
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943
--- Comment #13 from Alexander Westbrooks ---
I sent in the patch to those emails. Hopefully now the ball will start rolling
and I can slowly get this packaged into a legitimate fix. I'll post updates
here as I receive them.
The patch is below, if you would like to try it. I did this in the GCC 14 code.
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index d09c8bc97d9..9043a4d427f 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -4063,6 +4063,21 @@ gfc_get_pdt_instance (gfc_actual_arglist *param_list,
gfc_symbol **sym,
continue;
}
+ /*
+Addressing PR82943, this will fix the issue where a function/subroutine is
declared as not
+a member of the PDT instance. The reason for this is because the PDT
instance did not have
+access to its template's f2k_derived namespace in order to find the
typebound procedures.
+
+The number of references to the PDT template's f2k_derived will ensure
that f2k_derived is
+properly freed later on.
+ */
+
+ if (!instance->f2k_derived && pdt->f2k_derived)
+ {
+instance->f2k_derived = pdt->f2k_derived;
+instance->f2k_derived->refs++;
+ }
+
/* Set the component kind using the parameterized expression. */
if ((c1->ts.kind == 0 || c1->ts.type == BT_CHARACTER)
&& c1->kind_expr != NULL)
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index a58c60e9828..6854edb3467 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3536,6 +3536,7 @@ void gfc_traverse_gsymbol (gfc_gsymbol *, void
(*)(gfc_gsymbol *, void *), void
gfc_typebound_proc* gfc_get_typebound_proc (gfc_typebound_proc*);
gfc_symbol* gfc_get_derived_super_type (gfc_symbol*);
bool gfc_type_is_extension_of (gfc_symbol *, gfc_symbol *);
+bool gfc_pdt_is_instance_of(gfc_symbol *, gfc_symbol *);
bool gfc_type_compatible (gfc_typespec *, gfc_typespec *);
void gfc_copy_formal_args_intr (gfc_symbol *, gfc_intrinsic_sym *,
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 50b49d0cb83..6af55760321 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -14705,14 +14705,34 @@ resolve_typebound_procedure (gfc_symtree* stree)
goto error;
}
- if (CLASS_DATA (me_arg)->ts.u.derived
- != resolve_bindings_derived)
- {
- gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of"
-" the derived-type %qs", me_arg->name, proc->name,
-me_arg->name, , resolve_bindings_derived->name);
- goto error;
- }
+ /* The derived type is not a PDT template. Resolve as usual */
+ if ( !resolve_bindings_derived->attr.pdt_template &&
+(CLASS_DATA (me_arg)->ts.u.derived != resolve_bindings_derived))
+ {
+gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of"
+" the derived-type %qs", me_arg->name, proc->name,
+me_arg->name, , resolve_bindings_derived->name);
+goto error;
+ }
+
+ 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,
+ me_arg->name, , resolve_bindings_derived->name);
+goto error;
+ }
+
+ 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))
+ {
+gfc_error ("All LEN type parameters of the passed dummy argument %qs of
%qs"
+" at %L must be ASSUMED.", me_arg->name, proc->name, );
+goto error;
+ }
gcc_assert (me_arg->ts.type == BT_CLASS);
if (CLASS_DATA (me_arg)->as && CLASS_DATA (me_arg)->as->rank != 0)
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 37a9e8fa0ae..77f84de0989 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -5134,6 +5134,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
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 --- Comment #12 from kargl at gcc dot gnu.org --- (In reply to Alexander Westbrooks from comment #11) > (In reply to vegard from comment #10) > > (In reply to kargl from comment #9) > > > (In reply to alig from comment #8) > > > > The problem still persists with GNU Fortran (GCC) 11.1.0. > > > > > > The problem is likely to persist for the foreseeable future > > > as there is no one left to work on gfortran bugs. Lacking > > > a sudden influx of new volunteer contributors, it seems > > > the only way forward is to NOT use parameterized derived > > > types with gfortran. > > > > Any news here? I seem to be having this issue with gfortran (Homebrew GCC) > > 12.2.0 > > > > As a side note: I'm somewhat new to the fortran community, but could see > > myself contributing to gfortran in the future. Do you think you could point > > me to where I should read up on contributing? > > Hello! > > I'm new to the community as well. I have had the same issue with this bug > and first encountered it 5 years ago while working on my thesis. Two weeks > ago I decided to tackle this bug. I have found the issues in the code, and I > was able to successfully compiles the following example. I made sure that > the LEN type parameter condition was enforced as ja...@gcc.gnu.org stated in > Comment #6 and I used inheritance in this example to test the added logic to > ensure that a PDT instance belonged to a PDT template. > > The only things I have left to do is write applicable test cases (which I > haven't done before. I am learning how to use the DejaGNU framework as I > work on this) and obtain some guidance on how to get this code verified by > others and ultimately accepted as fixed code into the compiler. I am reading > the documentation of the GNU Fortran rules and I hope to get the test cases > completed and have the fix under review within the next couple of weeks. Your contribution will likely be most welcomed. I encourage you to send the patch to fort...@gcc.gnu.org and gcc-patc...@gcc.gnu.org to open up discussion. For testcases, look in gcc/testsuite/gfortran.dg for files with the string 'pdt' in the name. Copy one of those and adjust it to suit your needs.
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 Alexander Westbrooks changed: What|Removed |Added CC||ctechnodev at gmail dot com --- Comment #11 from Alexander Westbrooks --- (In reply to vegard from comment #10) > (In reply to kargl from comment #9) > > (In reply to alig from comment #8) > > > The problem still persists with GNU Fortran (GCC) 11.1.0. > > > > The problem is likely to persist for the foreseeable future > > as there is no one left to work on gfortran bugs. Lacking > > a sudden influx of new volunteer contributors, it seems > > the only way forward is to NOT use parameterized derived > > types with gfortran. > > Any news here? I seem to be having this issue with gfortran (Homebrew GCC) > 12.2.0 > > As a side note: I'm somewhat new to the fortran community, but could see > myself contributing to gfortran in the future. Do you think you could point > me to where I should read up on contributing? Hello! I'm new to the community as well. I have had the same issue with this bug and first encountered it 5 years ago while working on my thesis. Two weeks ago I decided to tackle this bug. I have found the issues in the code, and I was able to successfully compiles the following example. I made sure that the LEN type parameter condition was enforced as ja...@gcc.gnu.org stated in Comment #6 and I used inheritance in this example to test the added logic to ensure that a PDT instance belonged to a PDT template. The only things I have left to do is write applicable test cases (which I haven't done before. I am learning how to use the DejaGNU framework as I work on this) and obtain some guidance on how to get this code verified by others and ultimately accepted as fixed code into the compiler. I am reading the documentation of the GNU Fortran rules and I hope to get the test cases completed and have the fix under review within the next couple of weeks. module testmod public :: foo type, public :: tough_lvl_0(a, b) integer, kind :: a = 1 integer, len :: b contains procedure :: foo end type type, public, EXTENDS(tough_lvl_0) :: tough_lvl_1 (c) integer, len :: c contains procedure :: bar end type type, public, EXTENDS(tough_lvl_1) :: tough_lvl_2 (d) integer, len :: d contains procedure :: foobar end type contains subroutine foo(this) class(tough_lvl_0(1,*)), intent(inout) :: this end subroutine subroutine bar(this) class(tough_lvl_1(1,*,*)), intent(inout) :: this end subroutine subroutine foobar(this) class(tough_lvl_2(1,*,*,*)), intent(inout) :: this end subroutine end module PROGRAM testprogram USE testmod TYPE(tough_lvl_0(1,5)) :: test_pdt_0 TYPE(tough_lvl_1(1,5,6)) :: test_pdt_1 TYPE(tough_lvl_2(1,5,6,7)) :: test_pdt_2 CALL test_pdt_0%foo() CALL test_pdt_1%foo() CALL test_pdt_1%bar() CALL test_pdt_2%foo() CALL test_pdt_2%bar() CALL test_pdt_2%foobar() END PROGRAM testprogram
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 vegard changed: What|Removed |Added CC||vegard.g.j at icloud dot com --- Comment #10 from vegard --- (In reply to kargl from comment #9) > (In reply to alig from comment #8) > > The problem still persists with GNU Fortran (GCC) 11.1.0. > > The problem is likely to persist for the foreseeable future > as there is no one left to work on gfortran bugs. Lacking > a sudden influx of new volunteer contributors, it seems > the only way forward is to NOT use parameterized derived > types with gfortran. Any news here? I seem to be having this issue with gfortran (Homebrew GCC) 12.2.0 As a side note: I'm somewhat new to the fortran community, but could see myself contributing to gfortran in the future. Do you think you could point me to where I should read up on contributing?
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #9 from kargl at gcc dot gnu.org --- (In reply to alig from comment #8) > The problem still persists with GNU Fortran (GCC) 11.1.0. The problem is likely to persist for the foreseeable future as there is no one left to work on gfortran bugs. Lacking a sudden influx of new volunteer contributors, it seems the only way forward is to NOT use parameterized derived types with gfortran.
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 alig changed: What|Removed |Added CC||info at gha3mi dot com --- Comment #8 from alig --- The problem still persists with GNU Fortran (GCC) 11.1.0.
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 paul.luck...@rwth-aachen.de changed: What|Removed |Added CC||paul.luck...@rwth-aachen.de --- Comment #7 from paul.luck...@rwth-aachen.de --- Still arises in gfortran V10.1
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943
--- Comment #6 from janus at gcc dot gnu.org ---
Actually the patch is better expressed as:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index a2beb7fc90a..4710b7d2975 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -13433,8 +13433,9 @@ resolve_typebound_procedure (gfc_symtree* stree)
goto error;
}
- if (CLASS_DATA (me_arg)->ts.u.derived
- != resolve_bindings_derived)
+ if ((CLASS_DATA (me_arg)->ts.u.derived != resolve_bindings_derived) &&
+ !(resolve_bindings_derived->attr.pdt_template
+ && CLASS_DATA (me_arg)->ts.u.derived->attr.pdt_type))
{
gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of"
" the derived-type %qs", me_arg->name, proc->name,
But one still needs to make sure that the PDT template and the PDT type
actually belong to each other and enforce another condition: "All length type
parameters of the passed object dummy argument must be assumed." (as ifort puts
it)
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943
--- Comment #5 from janus at gcc dot gnu.org ---
One can get around the error with a patch like this:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index a2beb7fc90a..6b6e34c0d86 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -13433,8 +13433,9 @@ resolve_typebound_procedure (gfc_symtree* stree)
goto error;
}
- if (CLASS_DATA (me_arg)->ts.u.derived
- != resolve_bindings_derived)
+ if ((CLASS_DATA (me_arg)->ts.u.derived != resolve_bindings_derived) &&
+ !(resolve_bindings_derived->attr.pdt_template
+ && gfc_str_startswith (CLASS_DATA (me_arg)->ts.u.derived->name,
"Pdt")))
{
gfc_error ("Argument %qs of %qs with PASS(%s) at %L must be of"
" the derived-type %qs", me_arg->name, proc->name,
It is sufficient to accept the code in comment #4, but otherwise not fully
complete. With this patch, the code in comment #0 is still rejected:
29 |call b%foo()
| 1
Error: ‘foo’ at (1) is not a member of the ‘pdttypedef’ structure
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid CC||janus at gcc dot gnu.org Summary|Error derived type-bound|[F03] Error with type-bound |procedure PASS(this)|procedure of parametrized ||derived type --- Comment #4 from janus at gcc dot gnu.org --- Reduced test case for the error: module testmod public :: foo type, public :: t(n) integer, len :: n = 1 contains procedure :: foo end type contains subroutine foo(this) class(t(*)), intent(inout) :: this end subroutine end module procedure :: foo 1 Error: Argument ‘this’ of ‘foo’ with PASS(this) at (1) must be of the derived-type ‘t’
