This is an update of the derived-param patch from yesterday, which enables 
component initialization from KIND parameter.
Tested with the following program:

program mytype

  type goodtype (p1, p2, p3, p4)
    integer, kind       :: p1, p2, p3, p4
    real(p1)            :: c1
    integer(p2)         :: c2=p1
    complex             :: c3(p3)
  end type goodtype

  type(goodtype(4, 4, 3, 1)) :: mygood
  mygood%c1 = 1.5
  mygood%c3 = (/(1, 2), (3, 4), (5, 6)/)
  print *, mygood%c1
  print *, mygood%c2
  print *, mygood%c3

end program mytype
 

Thanks!
Sa



> > Hi All,
> > 
> > I've got an initial patch for KIND parameter of derived type. This 
> > patch (derived-param) is based on the one (derived-parse) provided 
> > by Paul in the original design. I've attached both to this mail.
> > 
> > The implementation is a bit different from the original design concept. 
> > In derived-type-stmt, the type-param-name-list is parsed and 
> > parameters are saved in a gfc_formal_arglist of type symbol. When 
> > using these parameters to define components, they are checked to be 
> > present in the formal_arglist.
> > 
> > I introduced a new field params in gfc_typespec to record actual 
> > parameter list in their original order.If not a derived type or 
> > there is no parameters given for the derived type, this field is set
> > to NULL. When comparing derived types, it the *derived symbol are 
> > the same, we then need to go through the *params list and compare 
> > each pair of actual arguments.
> > 
> >    typedef struct
> >    {
> >      bt type;
> >      int kind;
> >      struct gfc_symbol *derived;
> >   + struct gfc_actual_arglist *params; /* For derived type to keep 
> > parameter list.  */
> >      gfc_charlen *cl;      /* For character types only.  */
> >      struct gfc_symbol *interface; /* For PROCEDURE declarations.  */
> >      int is_c_interop;
> >      int is_iso_c;
> >      bt f90_type;
> >    }
> >    gfc_typespec;
> > 
> > This field is also temporarily used for a non-derived component, 
> > which is initialized by a KIND parameter. I suppose to use the same 
> > field for different purpose is somehow ugly and error-prone, but 
> > currently I have no better idea how to keep tracing the KIND 
> > parameters without changing too much in the data structure.
> > 
> > If the parameterized dt variables are defined in a module, we need 
> > to write the typespec with actual_arglist in the mod file, so that 
> > programs using this module can rebuild the proper typespec again.
> > 
> > So far, this patch enables derived-type definition and variable 
> > declaration with KIND type parameters. I've tested with the 
> > following test program:
> > 
> > program mytype
> > 
> >   type goodtype (p1, p2, p3, p4)
> >     integer, kind       :: p1, p2, p3, p4
> >     real(p1)            :: c1
> >     integer(p2)         :: c2
> >     complex             :: c3(p3)
> >   end type goodtype
> > 
> >   type(goodtype(4, 4, 3, 1)) :: mygood
> >   mygood%c1 = 1.5
> >   mygood%c2 = 5
> >   mygood%c3 = (/(1, 2), (3, 4), (5, 6)/)
> >   print *, mygood%c1
> >   print *, mygood%c2
> >   print *, mygood%c3
> > 
> > end program mytype
> > 
> > It is *not* yet tested against gfortran testsuites. I just want to 
> > get some feedback from you and to make sure whether I should 
> > continue with the implementation. Is this approach going to be 
> > applicable and acceptable? Is there any effect or influence to other
> > components? Any remark or suggestion will be appreciated!