https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543
--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Sat, Jun 06, 2020 at 05:13:31PM +0000, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543 > > --- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- > On Sat, Jun 06, 2020 at 04:34:53PM +0000, kargl at gcc dot gnu.org wrote: > > > > This cures the ICE, which then I believe leads to wrong-code. > > > > PDT are completely broken. When this is parsed > > type t(a, b) > integer, kind :: a = 1 > integer, kind :: b = a > end type > > the internal representation of for 't' has two components; > namely, a component for 'a' and a component for 'b'. Neither > 'a' nor 'b' is a component, and should therefore not be > in the link list of components. All of the programs in this > bug report should likely print nothing. > A little debugging shows *ts->u.derived->param_list = 0x0 ts->u.derived->components->name = 'a' ts->u.derived->components->next->name = 'b' It seems that param_list is populated when the derived type definition is used in an actual derived type declaration, ie., type(t(b=6)) would have a param_list item for 'b'. Looking in gfortran.h shows param_list is a 'gfc_actual_arglist *' type, ie., a list of actual arguments. Probably not a bad idea, since 't(b=6,a=4)' is valid and 'a' and 'b' can be treated as-if they are actual arguments to a function 't'. components are 'gfc_symbol *', so we cannot simply move then to the param_list.
