Discussion:
[Patch, fortran] Parameterized Derived Types
Paul Richard Thomas
2017-09-06 13:04:45 UTC
Permalink
Dear All,

Since my message to the list of 16 August 2017 I have put in another
intense period of activity to develop a patch to implement PDTs in
gfortran. I have now temporarily run out of time to develop it
further; partly because of a backlog of other patches and PRs to deal
with but also pressure from daytime work.

The patch adds the last unimplemented F2003 feature to gfortran.

As in the provisional patch, I have attached some notes on the
implementation. This indicates some of the weaknesses, problem areas
and TODOs.

Suggest that a good read of Mark Leair's excellent PGInsider article
on PDTs - http://www.pgroup.com/lit/articles/insider/v5n2a4.htm is a
worthwhile exercise.

To judge by the complete silence following my previous message, I will
have a problem getting this patch reviewed. I would welcome any
remarks or reviews but intend to commit, warts and all, on Saturday
unless something fundamentally wrong comes out of the woodwork.

Note that the PDT parts in the compiler are rather well insulated from
the rest of fortran and that I do not believe that any regressions
will result.

I hope that a month or two of testing in other hands will add to the
list of TODOs and that when I return to PDTs a greatly improved
version will result.

Bootstrapped and regtested on FC23/x86_4 - OK for trunk? (Note above
remark about committing on Saturday in the absence of a review.)

Best regards

Paul

2017-09-05 Paul Thomas <***@gcc.gnu.org>

* decl.c : Add decl_type_param_list, type_param_spec_list as
static variables to hold PDT spec lists.
(build_sym): Copy 'type_param_spec_list' to symbol spec_list.
(build_struct): Copy the 'saved_kind_expr' to the component
'kind_expr'. Check that KIND or LEN components appear in the
decl_type_param_list. These should appear as symbols in the
f2k_derived namespace. If the component is itself a PDT type,
copy the decl_type_param_list to the component param_list.
(gfc_match_kind_spec): If the KIND expression is parameterized
set KIND to zero and store the expression in 'saved_kind_expr'.
(insert_parameter_exprs): New function.
(gfc_insert_kind_parameter_exprs): New function.
(gfc_insert_parameter_exprs): New function.
(gfc_get_pdt_instance): New function.
(gfc_match_decl_type_spec): Match the decl_type_spec_list if it
is present. If it is, call 'gfc_get_pdt_instance' to obtain the
specific instance of the PDT.
(match_attr_spec): Match KIND and LEN attributes. Check for the
standard and for type/kind of the parameter. They are also not
allowed outside a derived type definition.
(gfc_match_data_decl): Null the decl_type_param_list and the
type_param_spec_list on entry and free them on exit.
(gfc_match_formal_arglist): If 'typeparam' is true, add the
formal symbol to the f2k_derived namespace.
(gfc_match_derived_decl): Register the decl_type_param_list
if this is a PDT. If this is a type extension, gather up all
the type parameters and put them in the right order.
*dump-parse-tree.c (show_attr): Signal PDT templates and the
parameter attributes.
(show_components): Output parameter atrributes and component
parameter list.
(show_symbol): Show variable parameter lists.
* expr.c (expr.c): Copy the expression parameter list.
(gfc_is_constant_expr): Pass on symbols representing PDT
parameters.
(gfc_check_init_expr): Break on PDT KIND parameters and
PDT parameter expressions.
(gfc_check_assign): Assigning to KIND or LEN components is an
error.
(derived_parameter_expr): New function.
(gfc_derived_parameter_expr): New function.
(gfc_spec_list_type): New function.
* gfortran.h : Add enum gfc_param_spec_type. Add the PDT attrs
to the structure symbol_attr. Add the 'kind_expr' and
'param_list' field to the gfc_component structure. Comment on
the reuse of the gfc_actual_arglist structure as storage for
type parameter spec lists. Add the new field 'spec_type' to
this structure. Add 'param_list' fields to gfc_symbol and
gfc_expr. Add prototypes for gfc_insert_kind_parameter_exprs,
gfc_insert_parameter_exprs, gfc_add_kind, gfc_add_len,
gfc_derived_parameter_expr and gfc_spec_list_type.
* interface.c (gfc_compare_derived_types): Treat PDTs in the
same way as sequence types.
* match.c : Add variable 'type_param_spec_list'.
(gfc_op2string, gfc_match_member_sep, gfc_match_label): Remove
trailing whitespace.
(match_derived_type_spec): Match PDTs and find specific
instance.
(gfc_match_type_spec): Remove more trailing whitespace.
(gfc_match_allocate): Assumed or deferred parameters cannot
appear here. Copy the type parameter spec list to the expr for
the allocatable entity. Free 'type_param_spec_list'.
(gfc_match_common, gfc_match_namelist, gfc_match_module): Still
more trailing whitespace to remove.
(gfc_match_type_is): Allow PDT typespecs.
* match.h : Modify prototypes for gfc_match_formal_arglist and
gfc_match_actual_arglist.
* module.c (ab_attribute, mstring attr_bits): PDT attributes
added.
(mio_symbol_attribute): PDT attributes handled.
(mio_component): Deal with 'kind_expr' field.
(mio_full_f2k_derived): For PDT templates, transfer the formal
namespace symroot to the f2k_derived namespace.
*primary.c (match_keyword_arg, gfc_match_actual_arglist): Add
modifications to handle PDT spec lists. These are flagged in
both cases by new boolean arguments, whose prototype defaults
are false.
(gfc_match_structure_constructor, match_variable): Remove yet
more trailing whitespace.
* resolve.c (get_pdt_spec_expr, get_pdt_constructor): New
functions.
(resolve_structure_cons): If the constructor is a PDT template,
call get_pdt_constructor to build it using the parameter lists
and then get the specific instance of the PDT.
(resolve_component): PDT strings need a hidden string length
component like deferred characters.
(resolve_symbol): Dummy PDTs cannot have deferred parameters.
* symbol.c (gfc_add_kind, gfc_add_len): New functions.
(free_components): Free 'kind_expr' and 'param_list' fields.
(gfc_free_symbol): Free the 'param_list' field.
(gfc_find_sym_tree): If the current state is a PDT template,
look for the symtree in the f2k_derived namspaces.
trans-array.c (structure_alloc_comps): Allocate and deallocate
PDTs. Check dummy arguments for compliance of LEN parameters.
Add the new functions to the preceeding enum.
(gfc_allocate_pdt_comp, gfc_deallocate_pdt_comp and
gfc_check_pdt_dummy): New functions calling above.
* trans-array.h : Add prototypes for these functions.
trans-decl.c (gfc_get_symbol_decl): Call gfc_defer_symbol_init
as appropriate for PDT symbols.
(gfc_trans_deferred_vars): Allocate/deallocate PDT entities as
they come into and out of scope. Exclude pdt_types from being
'gcc_unreachable'.
(gfc_trans_subcomponent_assign): PDT array components must be
handles as if they are allocatable.
* trans-stmt.c (gfc_trans_allocate): Handle initialization of
PDT entities.
(gfc_trans_deallocate): Likewise.
* trans-types.c (gfc_get_derived_type): PDT templates must not
arrive here. PDT string components are handles as if deferred.
Similarly, PDT arrays are treated as if allocatable. PDT
strings are pointer types.
* trans.c (gfc_deferred_strlen): Handle PDT strings in the same
way as deferred characters.


2017-09-05 Paul Thomas <***@gcc.gnu.org>

* gfortran.dg/pdt_1.f03 : New test.
* gfortran.dg/pdt_2.f03 : New test.
* gfortran.dg/pdt_3.f03 : New test.
* gfortran.dg/pdt_4.f03 : New test.
* gfortran.dg/pdt_5.f03 : New test.
Paul Richard Thomas
2017-09-06 14:55:10 UTC
Permalink
Dear All,

Since my message to the list of 16 August 2017 I have put in another
intense period of activity to develop a patch to implement PDTs in
gfortran. I have now temporarily run out of time to develop it
further; partly because of a backlog of other patches and PRs to deal
with but also pressure from daytime work.

The patch adds the last unimplemented F2003 feature to gfortran.

As in the provisional patch, I have attached some notes on the
implementation. This indicates some of the weaknesses, problem areas
and TODOs.

Suggest that a good read of Mark Leair's excellent PGInsider article
on PDTs - http://www.pgroup.com/lit/articles/insider/v5n2a4.htm is a
worthwhile exercise.

To judge by the complete silence following my previous message, I will
have a problem getting this patch reviewed. I would welcome any
remarks or reviews but intend to commit, warts and all, on Saturday
unless something fundamentally wrong comes out of the woodwork.

Note that the PDT parts in the compiler are rather well insulated from
the rest of fortran and that I do not believe that any regressions
will result.

I hope that a month or two of testing in other hands will add to the
list of TODOs and that when I return to PDTs a greatly improved
version will result.

Bootstrapped and regtested on FC23/x86_4 - OK for trunk? (Note above
remark about committing on Saturday in the absence of a review.)

Best regards

Paul

2017-09-05 Paul Thomas <***@gcc.gnu.org>

* decl.c : Add decl_type_param_list, type_param_spec_list as
static variables to hold PDT spec lists.
(build_sym): Copy 'type_param_spec_list' to symbol spec_list.
(build_struct): Copy the 'saved_kind_expr' to the component
'kind_expr'. Check that KIND or LEN components appear in the
decl_type_param_list. These should appear as symbols in the
f2k_derived namespace. If the component is itself a PDT type,
copy the decl_type_param_list to the component param_list.
(gfc_match_kind_spec): If the KIND expression is parameterized
set KIND to zero and store the expression in 'saved_kind_expr'.
(insert_parameter_exprs): New function.
(gfc_insert_kind_parameter_exprs): New function.
(gfc_insert_parameter_exprs): New function.
(gfc_get_pdt_instance): New function.
(gfc_match_decl_type_spec): Match the decl_type_spec_list if it
is present. If it is, call 'gfc_get_pdt_instance' to obtain the
specific instance of the PDT.
(match_attr_spec): Match KIND and LEN attributes. Check for the
standard and for type/kind of the parameter. They are also not
allowed outside a derived type definition.
(gfc_match_data_decl): Null the decl_type_param_list and the
type_param_spec_list on entry and free them on exit.
(gfc_match_formal_arglist): If 'typeparam' is true, add the
formal symbol to the f2k_derived namespace.
(gfc_match_derived_decl): Register the decl_type_param_list
if this is a PDT. If this is a type extension, gather up all
the type parameters and put them in the right order.
*dump-parse-tree.c (show_attr): Signal PDT templates and the
parameter attributes.
(show_components): Output parameter atrributes and component
parameter list.
(show_symbol): Show variable parameter lists.
* expr.c (expr.c): Copy the expression parameter list.
(gfc_is_constant_expr): Pass on symbols representing PDT
parameters.
(gfc_check_init_expr): Break on PDT KIND parameters and
PDT parameter expressions.
(gfc_check_assign): Assigning to KIND or LEN components is an
error.
(derived_parameter_expr): New function.
(gfc_derived_parameter_expr): New function.
(gfc_spec_list_type): New function.
* gfortran.h : Add enum gfc_param_spec_type. Add the PDT attrs
to the structure symbol_attr. Add the 'kind_expr' and
'param_list' field to the gfc_component structure. Comment on
the reuse of the gfc_actual_arglist structure as storage for
type parameter spec lists. Add the new field 'spec_type' to
this structure. Add 'param_list' fields to gfc_symbol and
gfc_expr. Add prototypes for gfc_insert_kind_parameter_exprs,
gfc_insert_parameter_exprs, gfc_add_kind, gfc_add_len,
gfc_derived_parameter_expr and gfc_spec_list_type.
* interface.c (gfc_compare_derived_types): Treat PDTs in the
same way as sequence types.
* match.c : Add variable 'type_param_spec_list'.
(gfc_op2string, gfc_match_member_sep, gfc_match_label): Remove
trailing whitespace.
(match_derived_type_spec): Match PDTs and find specific
instance.
(gfc_match_type_spec): Remove more trailing whitespace.
(gfc_match_allocate): Assumed or deferred parameters cannot
appear here. Copy the type parameter spec list to the expr for
the allocatable entity. Free 'type_param_spec_list'.
(gfc_match_common, gfc_match_namelist, gfc_match_module): Still
more trailing whitespace to remove.
(gfc_match_type_is): Allow PDT typespecs.
* match.h : Modify prototypes for gfc_match_formal_arglist and
gfc_match_actual_arglist.
* module.c (ab_attribute, mstring attr_bits): PDT attributes
added.
(mio_symbol_attribute): PDT attributes handled.
(mio_component): Deal with 'kind_expr' field.
(mio_full_f2k_derived): For PDT templates, transfer the formal
namespace symroot to the f2k_derived namespace.
*primary.c (match_keyword_arg, gfc_match_actual_arglist): Add
modifications to handle PDT spec lists. These are flagged in
both cases by new boolean arguments, whose prototype defaults
are false.
(gfc_match_structure_constructor, match_variable): Remove yet
more trailing whitespace.
* resolve.c (get_pdt_spec_expr, get_pdt_constructor): New
functions.
(resolve_structure_cons): If the constructor is a PDT template,
call get_pdt_constructor to build it using the parameter lists
and then get the specific instance of the PDT.
(resolve_component): PDT strings need a hidden string length
component like deferred characters.
(resolve_symbol): Dummy PDTs cannot have deferred parameters.
* symbol.c (gfc_add_kind, gfc_add_len): New functions.
(free_components): Free 'kind_expr' and 'param_list' fields.
(gfc_free_symbol): Free the 'param_list' field.
(gfc_find_sym_tree): If the current state is a PDT template,
look for the symtree in the f2k_derived namspaces.
trans-array.c (structure_alloc_comps): Allocate and deallocate
PDTs. Check dummy arguments for compliance of LEN parameters.
Add the new functions to the preceeding enum.
(gfc_allocate_pdt_comp, gfc_deallocate_pdt_comp and
gfc_check_pdt_dummy): New functions calling above.
* trans-array.h : Add prototypes for these functions.
trans-decl.c (gfc_get_symbol_decl): Call gfc_defer_symbol_init
as appropriate for PDT symbols.
(gfc_trans_deferred_vars): Allocate/deallocate PDT entities as
they come into and out of scope. Exclude pdt_types from being
'gcc_unreachable'.
(gfc_trans_subcomponent_assign): PDT array components must be
handles as if they are allocatable.
* trans-stmt.c (gfc_trans_allocate): Handle initialization of
PDT entities.
(gfc_trans_deallocate): Likewise.
* trans-types.c (gfc_get_derived_type): PDT templates must not
arrive here. PDT string components are handles as if deferred.
Similarly, PDT arrays are treated as if allocatable. PDT
strings are pointer types.
* trans.c (gfc_deferred_strlen): Handle PDT strings in the same
way as deferred characters.


2017-09-05 Paul Thomas <***@gcc.gnu.org>

* gfortran.dg/pdt_1.f03 : New test.
* gfortran.dg/pdt_2.f03 : New test.
* gfortran.dg/pdt_3.f03 : New test.
* gfortran.dg/pdt_4.f03 : New test.
* gfortran.dg/pdt_5.f03 : New test.
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Janus Weil
2017-09-06 17:38:29 UTC
Permalink
Hi Paul,

thanks for your patch! It's really great to finally see PDTs come to
gfortran. You're a hero, man ;)

Also: Sorry about the silence. It's certainly not due to lack of
interest, but rather lack of time (day job and private life taking up
all of mine at the moment).

In my current situation I can not promise a complete review of this
beast of a patch, but I will try to do some testing and at least skim
over the diff. I will probably not get to it before the weekend,
though.

Cheers,
Janus
Post by Paul Richard Thomas
Dear All,
Since my message to the list of 16 August 2017 I have put in another
intense period of activity to develop a patch to implement PDTs in
gfortran. I have now temporarily run out of time to develop it
further; partly because of a backlog of other patches and PRs to deal
with but also pressure from daytime work.
The patch adds the last unimplemented F2003 feature to gfortran.
As in the provisional patch, I have attached some notes on the
implementation. This indicates some of the weaknesses, problem areas
and TODOs.
Suggest that a good read of Mark Leair's excellent PGInsider article
on PDTs - http://www.pgroup.com/lit/articles/insider/v5n2a4.htm is a
worthwhile exercise.
To judge by the complete silence following my previous message, I will
have a problem getting this patch reviewed. I would welcome any
remarks or reviews but intend to commit, warts and all, on Saturday
unless something fundamentally wrong comes out of the woodwork.
Note that the PDT parts in the compiler are rather well insulated from
the rest of fortran and that I do not believe that any regressions
will result.
I hope that a month or two of testing in other hands will add to the
list of TODOs and that when I return to PDTs a greatly improved
version will result.
Bootstrapped and regtested on FC23/x86_4 - OK for trunk? (Note above
remark about committing on Saturday in the absence of a review.)
Best regards
Paul
* decl.c : Add decl_type_param_list, type_param_spec_list as
static variables to hold PDT spec lists.
(build_sym): Copy 'type_param_spec_list' to symbol spec_list.
(build_struct): Copy the 'saved_kind_expr' to the component
'kind_expr'. Check that KIND or LEN components appear in the
decl_type_param_list. These should appear as symbols in the
f2k_derived namespace. If the component is itself a PDT type,
copy the decl_type_param_list to the component param_list.
(gfc_match_kind_spec): If the KIND expression is parameterized
set KIND to zero and store the expression in 'saved_kind_expr'.
(insert_parameter_exprs): New function.
(gfc_insert_kind_parameter_exprs): New function.
(gfc_insert_parameter_exprs): New function.
(gfc_get_pdt_instance): New function.
(gfc_match_decl_type_spec): Match the decl_type_spec_list if it
is present. If it is, call 'gfc_get_pdt_instance' to obtain the
specific instance of the PDT.
(match_attr_spec): Match KIND and LEN attributes. Check for the
standard and for type/kind of the parameter. They are also not
allowed outside a derived type definition.
(gfc_match_data_decl): Null the decl_type_param_list and the
type_param_spec_list on entry and free them on exit.
(gfc_match_formal_arglist): If 'typeparam' is true, add the
formal symbol to the f2k_derived namespace.
(gfc_match_derived_decl): Register the decl_type_param_list
if this is a PDT. If this is a type extension, gather up all
the type parameters and put them in the right order.
*dump-parse-tree.c (show_attr): Signal PDT templates and the
parameter attributes.
(show_components): Output parameter atrributes and component
parameter list.
(show_symbol): Show variable parameter lists.
* expr.c (expr.c): Copy the expression parameter list.
(gfc_is_constant_expr): Pass on symbols representing PDT
parameters.
(gfc_check_init_expr): Break on PDT KIND parameters and
PDT parameter expressions.
(gfc_check_assign): Assigning to KIND or LEN components is an
error.
(derived_parameter_expr): New function.
(gfc_derived_parameter_expr): New function.
(gfc_spec_list_type): New function.
* gfortran.h : Add enum gfc_param_spec_type. Add the PDT attrs
to the structure symbol_attr. Add the 'kind_expr' and
'param_list' field to the gfc_component structure. Comment on
the reuse of the gfc_actual_arglist structure as storage for
type parameter spec lists. Add the new field 'spec_type' to
this structure. Add 'param_list' fields to gfc_symbol and
gfc_expr. Add prototypes for gfc_insert_kind_parameter_exprs,
gfc_insert_parameter_exprs, gfc_add_kind, gfc_add_len,
gfc_derived_parameter_expr and gfc_spec_list_type.
* interface.c (gfc_compare_derived_types): Treat PDTs in the
same way as sequence types.
* match.c : Add variable 'type_param_spec_list'.
(gfc_op2string, gfc_match_member_sep, gfc_match_label): Remove
trailing whitespace.
(match_derived_type_spec): Match PDTs and find specific
instance.
(gfc_match_type_spec): Remove more trailing whitespace.
(gfc_match_allocate): Assumed or deferred parameters cannot
appear here. Copy the type parameter spec list to the expr for
the allocatable entity. Free 'type_param_spec_list'.
(gfc_match_common, gfc_match_namelist, gfc_match_module): Still
more trailing whitespace to remove.
(gfc_match_type_is): Allow PDT typespecs.
* match.h : Modify prototypes for gfc_match_formal_arglist and
gfc_match_actual_arglist.
* module.c (ab_attribute, mstring attr_bits): PDT attributes
added.
(mio_symbol_attribute): PDT attributes handled.
(mio_component): Deal with 'kind_expr' field.
(mio_full_f2k_derived): For PDT templates, transfer the formal
namespace symroot to the f2k_derived namespace.
*primary.c (match_keyword_arg, gfc_match_actual_arglist): Add
modifications to handle PDT spec lists. These are flagged in
both cases by new boolean arguments, whose prototype defaults
are false.
(gfc_match_structure_constructor, match_variable): Remove yet
more trailing whitespace.
* resolve.c (get_pdt_spec_expr, get_pdt_constructor): New
functions.
(resolve_structure_cons): If the constructor is a PDT template,
call get_pdt_constructor to build it using the parameter lists
and then get the specific instance of the PDT.
(resolve_component): PDT strings need a hidden string length
component like deferred characters.
(resolve_symbol): Dummy PDTs cannot have deferred parameters.
* symbol.c (gfc_add_kind, gfc_add_len): New functions.
(free_components): Free 'kind_expr' and 'param_list' fields.
(gfc_free_symbol): Free the 'param_list' field.
(gfc_find_sym_tree): If the current state is a PDT template,
look for the symtree in the f2k_derived namspaces.
trans-array.c (structure_alloc_comps): Allocate and deallocate
PDTs. Check dummy arguments for compliance of LEN parameters.
Add the new functions to the preceeding enum.
(gfc_allocate_pdt_comp, gfc_deallocate_pdt_comp and
gfc_check_pdt_dummy): New functions calling above.
* trans-array.h : Add prototypes for these functions.
trans-decl.c (gfc_get_symbol_decl): Call gfc_defer_symbol_init
as appropriate for PDT symbols.
(gfc_trans_deferred_vars): Allocate/deallocate PDT entities as
they come into and out of scope. Exclude pdt_types from being
'gcc_unreachable'.
(gfc_trans_subcomponent_assign): PDT array components must be
handles as if they are allocatable.
* trans-stmt.c (gfc_trans_allocate): Handle initialization of
PDT entities.
(gfc_trans_deallocate): Likewise.
* trans-types.c (gfc_get_derived_type): PDT templates must not
arrive here. PDT string components are handles as if deferred.
Similarly, PDT arrays are treated as if allocatable. PDT
strings are pointer types.
* trans.c (gfc_deferred_strlen): Handle PDT strings in the same
way as deferred characters.
* gfortran.dg/pdt_1.f03 : New test.
* gfortran.dg/pdt_2.f03 : New test.
* gfortran.dg/pdt_3.f03 : New test.
* gfortran.dg/pdt_4.f03 : New test.
* gfortran.dg/pdt_5.f03 : New test.
Damian Rouson
2017-09-06 18:37:26 UTC
Permalink
 
Thanks for your tireless efforts on this, Paul! I look forward to trying this out after it hits the trunk.

Your phrase “last unimplemented F2003” feature bolsters my suspicion that it might be ok to switch the features listed as “Partial” on the Fortran wiki to “Yes." I suppose the difference depends on developer intent. If the developer(s) intended to leave some aspect of a feature unimplemented (as might be evidenced by an appropriate compiler message), then “Partial” seems best. Otherwise, “Yes” seems appropriate even in the presence of bugs. I’ll send a separate email to the list with further thoughts on this.


Best Regards,
_______________________
Damian Rouson, Ph.D., P.E.
President, Sourcery Institute
www.sourceryinstitute.org(http://www.sourceryinstitute.org)
+1-510-600-2992 (mobile)
Post by Paul Richard Thomas
Dear All,
Since my message to the list of 16 August 2017 I have put in another
intense period of activity to develop a patch to implement PDTs in
gfortran. I have now temporarily run out of time to develop it
further; partly because of a backlog of other patches and PRs to deal
with but also pressure from daytime work.
The patch adds the last unimplemented F2003 feature to gfortran.
As in the provisional patch, I have attached some notes on the
implementation. This indicates some of the weaknesses, problem areas
and TODOs.
Suggest that a good read of Mark Leair's excellent PGInsider article
on PDTs - http://www.pgroup.com/lit/articles/insider/v5n2a4.htm is a
worthwhile exercise.
To judge by the complete silence following my previous message, I will
have a problem getting this patch reviewed. I would welcome any
remarks or reviews but intend to commit, warts and all, on Saturday
unless something fundamentally wrong comes out of the woodwork.
Note that the PDT parts in the compiler are rather well insulated from
the rest of fortran and that I do not believe that any regressions
will result.
I hope that a month or two of testing in other hands will add to the
list of TODOs and that when I return to PDTs a greatly improved
version will result.
Bootstrapped and regtested on FC23/x86_4 - OK for trunk? (Note above
remark about committing on Saturday in the absence of a review.)
Best regards
Paul
2017-09-05 Paul Thomas
* decl.c : Add decl_type_param_list, type_param_spec_list as
static variables to hold PDT spec lists.
(build_sym): Copy 'type_param_spec_list' to symbol spec_list.
(build_struct): Copy the 'saved_kind_expr' to the component
'kind_expr'. Check that KIND or LEN components appear in the
decl_type_param_list. These should appear as symbols in the
f2k_derived namespace. If the component is itself a PDT type,
copy the decl_type_param_list to the component param_list.
(gfc_match_kind_spec): If the KIND expression is parameterized
set KIND to zero and store the expression in 'saved_kind_expr'.
(insert_parameter_exprs): New function.
(gfc_insert_kind_parameter_exprs): New function.
(gfc_insert_parameter_exprs): New function.
(gfc_get_pdt_instance): New function.
(gfc_match_decl_type_spec): Match the decl_type_spec_list if it
is present. If it is, call 'gfc_get_pdt_instance' to obtain the
specific instance of the PDT.
(match_attr_spec): Match KIND and LEN attributes. Check for the
standard and for type/kind of the parameter. They are also not
allowed outside a derived type definition.
(gfc_match_data_decl): Null the decl_type_param_list and the
type_param_spec_list on entry and free them on exit.
(gfc_match_formal_arglist): If 'typeparam' is true, add the
formal symbol to the f2k_derived namespace.
(gfc_match_derived_decl): Register the decl_type_param_list
if this is a PDT. If this is a type extension, gather up all
the type parameters and put them in the right order.
*dump-parse-tree.c (show_attr): Signal PDT templates and the
parameter attributes.
(show_components): Output parameter atrributes and component
parameter list.
(show_symbol): Show variable parameter lists.
* expr.c (expr.c): Copy the expression parameter list.
(gfc_is_constant_expr): Pass on symbols representing PDT
parameters.
(gfc_check_init_expr): Break on PDT KIND parameters and
PDT parameter expressions.
(gfc_check_assign): Assigning to KIND or LEN components is an
error.
(derived_parameter_expr): New function.
(gfc_derived_parameter_expr): New function.
(gfc_spec_list_type): New function.
* gfortran.h : Add enum gfc_param_spec_type. Add the PDT attrs
to the structure symbol_attr. Add the 'kind_expr' and
'param_list' field to the gfc_component structure. Comment on
the reuse of the gfc_actual_arglist structure as storage for
type parameter spec lists. Add the new field 'spec_type' to
this structure. Add 'param_list' fields to gfc_symbol and
gfc_expr. Add prototypes for gfc_insert_kind_parameter_exprs,
gfc_insert_parameter_exprs, gfc_add_kind, gfc_add_len,
gfc_derived_parameter_expr and gfc_spec_list_type.
* interface.c (gfc_compare_derived_types): Treat PDTs in the
same way as sequence types.
* match.c : Add variable 'type_param_spec_list'.
(gfc_op2string, gfc_match_member_sep, gfc_match_label): Remove
trailing whitespace.
(match_derived_type_spec): Match PDTs and find specific
instance.
(gfc_match_type_spec): Remove more trailing whitespace.
(gfc_match_allocate): Assumed or deferred parameters cannot
appear here. Copy the type parameter spec list to the expr for
the allocatable entity. Free 'type_param_spec_list'.
(gfc_match_common, gfc_match_namelist, gfc_match_module): Still
more trailing whitespace to remove.
(gfc_match_type_is): Allow PDT typespecs.
* match.h : Modify prototypes for gfc_match_formal_arglist and
gfc_match_actual_arglist.
* module.c (ab_attribute, mstring attr_bits): PDT attributes
added.
(mio_symbol_attribute): PDT attributes handled.
(mio_component): Deal with 'kind_expr' field.
(mio_full_f2k_derived): For PDT templates, transfer the formal
namespace symroot to the f2k_derived namespace.
*primary.c (match_keyword_arg, gfc_match_actual_arglist): Add
modifications to handle PDT spec lists. These are flagged in
both cases by new boolean arguments, whose prototype defaults
are false.
(gfc_match_structure_constructor, match_variable): Remove yet
more trailing whitespace.
* resolve.c (get_pdt_spec_expr, get_pdt_constructor): New
functions.
(resolve_structure_cons): If the constructor is a PDT template,
call get_pdt_constructor to build it using the parameter lists
and then get the specific instance of the PDT.
(resolve_component): PDT strings need a hidden string length
component like deferred characters.
(resolve_symbol): Dummy PDTs cannot have deferred parameters.
* symbol.c (gfc_add_kind, gfc_add_len): New functions.
(free_components): Free 'kind_expr' and 'param_list' fields.
(gfc_free_symbol): Free the 'param_list' field.
(gfc_find_sym_tree): If the current state is a PDT template,
look for the symtree in the f2k_derived namspaces.
trans-array.c (structure_alloc_comps): Allocate and deallocate
PDTs. Check dummy arguments for compliance of LEN parameters.
Add the new functions to the preceeding enum.
(gfc_allocate_pdt_comp, gfc_deallocate_pdt_comp and
gfc_check_pdt_dummy): New functions calling above.
* trans-array.h : Add prototypes for these functions.
trans-decl.c (gfc_get_symbol_decl): Call gfc_defer_symbol_init
as appropriate for PDT symbols.
(gfc_trans_deferred_vars): Allocate/deallocate PDT entities as
they come into and out of scope. Exclude pdt_types from being
'gcc_unreachable'.
(gfc_trans_subcomponent_assign): PDT array components must be
handles as if they are allocatable.
* trans-stmt.c (gfc_trans_allocate): Handle initialization of
PDT entities.
(gfc_trans_deallocate): Likewise.
* trans-types.c (gfc_get_derived_type): PDT templates must not
arrive here. PDT string components are handles as if deferred.
Similarly, PDT arrays are treated as if allocatable. PDT
strings are pointer types.
* trans.c (gfc_deferred_strlen): Handle PDT strings in the same
way as deferred characters.
2017-09-05 Paul Thomas
* gfortran.dg/pdt_1.f03 : New test.
* gfortran.dg/pdt_2.f03 : New test.
* gfortran.dg/pdt_3.f03 : New test.
* gfortran.dg/pdt_4.f03 : New test.
* gfortran.dg/pdt_5.f03 : New test.
Paul Richard Thomas
2017-09-09 11:15:37 UTC
Permalink
Dear All,

The patch has been committed as revision 251925.

I look forward to "feedback" (aka PRs) in the coming weeks. I will
return to Parameterized Derived Types at the end of this month to
clear up some of the known deficiencies (see the notes attached to the
patch submission) and any PRs that arise.

Regards

Paul
Damian Rouson
2017-09-09 11:27:21 UTC
Permalink
 
Hooray!!!! Great work, Paul. I’ve already launched a build. 

One small step for gfortran.  One big step for the Fortran world.  I hope you’ll be announcing this on comp.lang.fortran.

:D
Post by Paul Richard Thomas
Dear All,
The patch has been committed as revision 251925.
I look forward to "feedback" (aka PRs) in the coming weeks. I will
return to Parameterized Derived Types at the end of this month to
clear up some of the known deficiencies (see the notes attached to the
patch submission) and any PRs that arise.
Regards
Paul
Janus Weil
2017-09-09 19:08:21 UTC
Permalink
Post by Damian Rouson
Hooray!!!! Great work, Paul.
+1 :D


As promised, I have done some testing by now, and found several
problems (ICE-on-invalid, accepts-invalid and rejects-valid), see the
attached test cases. Nothing too severe I guess.
Post by Damian Rouson
One small step for gfortran. One big step for the Fortran world.
I have never looked very closely into PDTs, but now that I do, it
seems like the step for the Fortran world is not quite as big as it
could be (or as I had hoped).

The restriction that KIND parameters cannot be assumed/deferred is a
pretty severe one, isn't it? In terms of "generic programming" it
makes PDTs far less powerful than e.g. C++ templates (I knew that they
are less powerful, but with this restriction it's worse than I
thought).

In particular, it seems that I can define a nice 'generic' type that
deals with arbitrary KIND values in theory, but then all the functions
/ TBPs that work on my type need to be implemented separately for each
KIND value (which means lots of cod duplication), right? Or am I
overlooking anything here? Is anyone aware if this restriction is
lifted in F08 or later, or is planned to be lifted?

Cheers,
Janus
Post by Damian Rouson
Post by Paul Richard Thomas
Dear All,
The patch has been committed as revision 251925.
I look forward to "feedback" (aka PRs) in the coming weeks. I will
return to Parameterized Derived Types at the end of this month to
clear up some of the known deficiencies (see the notes attached to the
patch submission) and any PRs that arise.
Regards
Paul
Paul Richard Thomas
2017-09-10 08:18:14 UTC
Permalink
Dear Janus,

Many thanks for doing some testing and for the failing testcases.

I agree that not allowing ASSUMED or DEFERRED KIND parameters is a
limitation. As far as I am aware there are no plans to change this but
there have been discussions concerning generic programming for F20xx
on clf. The consensus is that PDTs were a step in the wrong direction
:-) I was mulling over laying out how some of the proposals could be
implemented to add my 1 centime's worth to the discussion.

Cheers

Paul
Post by Janus Weil
Post by Damian Rouson
Hooray!!!! Great work, Paul.
+1 :D
As promised, I have done some testing by now, and found several
problems (ICE-on-invalid, accepts-invalid and rejects-valid), see the
attached test cases. Nothing too severe I guess.
Post by Damian Rouson
One small step for gfortran. One big step for the Fortran world.
I have never looked very closely into PDTs, but now that I do, it
seems like the step for the Fortran world is not quite as big as it
could be (or as I had hoped).
The restriction that KIND parameters cannot be assumed/deferred is a
pretty severe one, isn't it? In terms of "generic programming" it
makes PDTs far less powerful than e.g. C++ templates (I knew that they
are less powerful, but with this restriction it's worse than I
thought).
In particular, it seems that I can define a nice 'generic' type that
deals with arbitrary KIND values in theory, but then all the functions
/ TBPs that work on my type need to be implemented separately for each
KIND value (which means lots of cod duplication), right? Or am I
overlooking anything here? Is anyone aware if this restriction is
lifted in F08 or later, or is planned to be lifted?
Cheers,
Janus
Post by Damian Rouson
Post by Paul Richard Thomas
Dear All,
The patch has been committed as revision 251925.
I look forward to "feedback" (aka PRs) in the coming weeks. I will
return to Parameterized Derived Types at the end of this month to
clear up some of the known deficiencies (see the notes attached to the
patch submission) and any PRs that arise.
Regards
Paul
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Janus Weil
2017-09-11 20:23:10 UTC
Permalink
Post by Paul Richard Thomas
I agree that not allowing ASSUMED or DEFERRED KIND parameters is a
limitation. As far as I am aware there are no plans to change this but
there have been discussions concerning generic programming for F20xx
on clf. The consensus is that PDTs were a step in the wrong direction
I wouldn't say the direction is completely wrong, but certainly
F03-PDTs do not go far enough to provide full-blown generic
programming.

One problem is the limitation that I mentioned earlier. Another one is
the fact that PDTs only provide mechanisms that are generic among a
single type (with different kind and len parameters), but none that
are generic across different types (such as e.g. unlimited
polymorphism or C++ templates).
Post by Paul Richard Thomas
I was mulling over laying out how some of the proposals could be
implemented to add my 1 centime's worth to the discussion.
For the start, maybe you could comment on the question, whether it
would be feasible in your implementation of PDTs in gfortran to
support assumed/deferred KIND parameters (as a straightforward
extension to the F03 standard, without any conceptually-new
additions).

Certainly the compiler would have to do a bit more work, namely for
each PDT-generic function (i.e. one that takes a PDT argument)
generate different versions of the function for the supported / used
kind values. Do you think that's possible without too much effort? My
feeling is that it would be quite useful (I don't see myself using
PDTs anytime soon unless this limitation is lifted).

Cheers,
Janus
Post by Paul Richard Thomas
Post by Janus Weil
Post by Damian Rouson
Hooray!!!! Great work, Paul.
+1 :D
As promised, I have done some testing by now, and found several
problems (ICE-on-invalid, accepts-invalid and rejects-valid), see the
attached test cases. Nothing too severe I guess.
Post by Damian Rouson
One small step for gfortran. One big step for the Fortran world.
I have never looked very closely into PDTs, but now that I do, it
seems like the step for the Fortran world is not quite as big as it
could be (or as I had hoped).
The restriction that KIND parameters cannot be assumed/deferred is a
pretty severe one, isn't it? In terms of "generic programming" it
makes PDTs far less powerful than e.g. C++ templates (I knew that they
are less powerful, but with this restriction it's worse than I
thought).
In particular, it seems that I can define a nice 'generic' type that
deals with arbitrary KIND values in theory, but then all the functions
/ TBPs that work on my type need to be implemented separately for each
KIND value (which means lots of cod duplication), right? Or am I
overlooking anything here? Is anyone aware if this restriction is
lifted in F08 or later, or is planned to be lifted?
Cheers,
Janus
Post by Damian Rouson
Post by Paul Richard Thomas
Dear All,
The patch has been committed as revision 251925.
I look forward to "feedback" (aka PRs) in the coming weeks. I will
return to Parameterized Derived Types at the end of this month to
clear up some of the known deficiencies (see the notes attached to the
patch submission) and any PRs that arise.
Regards
Paul
--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Bernhard Reutner-Fischer
2018-09-07 08:42:49 UTC
Permalink
On Sat, 9 Sep 2017 at 13:15, Paul Richard Thomas
Post by Paul Richard Thomas
Dear All,
The patch has been committed as revision 251925.
I look forward to "feedback" (aka PRs) in the coming weeks. I will
nit: s/uneeded/unneeded/
(as is this nit ;)

cheers,

Loading...