Re: [Patch, fortran] Initializing components of derived type variables

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Fri, Mar 04, 2016 at 11:42:48AM -0500, Fritz Reese wrote:
> 
> Here I propose a patch to gfortran which allows initializing
> components of derived type variables with a new compile flag.
> 
> Currently the options -finit-integer=, -finit-real=, -finit-logical=,
> and -finit-character= are avaialable to initialize variables of each
> respective type; however, there is no way (other than explicitly in
> source) to initialize derived type variables.
> 
> In this patch I add the flag -finit-derived. This flag allows
> components of derived type variables to be initialized as with local
> variables. This flag obeys the values given to the other -finit-*=
> flags; with -finit-local-zero derived type variables are initialized
> to zero.
> 
> The brunt of the work happens in expr.c (gfc_default_initializer). I
> add a boolean parameter to gfc_default_initializer which indicates
> whether or not to generate initializers for components that do not
> already have them. If true, an expression is generated for each
> component which does not already have an explicit initializer.
> 
> This parameter is passed potentially as true in two places in
> resolve.c (apply_default_init and resolve_fl_variable_derived).
> Generation is guarded by can_create_initializer, which ensures similar
> conditions as in resolve.c (build_default_init_expr).
> 
> To do the generation, gfc_default_initializer calls upon a new
> function component_init in expr.c. In order to use the -finit-* flags
> this calls upon the behavior formerly implemented in resolve.c
> (build_default_init_expr); I moved this behavior to the public
> function gfc_build_default_init_expr in expr.c;
> build_default_init_expr in resolve.c now simply wraps this function to
> protect it from being called on invalid symbols.
> 
> I wrestled with whether to change the interface for
> gfc_default_initializer or create an entirely new function (like
> gfc_generate_derived_initializer). I decided to change the old
> function because their behaviors would be almost identical, and there
> are only a few calls to the former.
> 
> The patch is based on trunk. It builds and passes all regression tests
> on x86-64-gnu-linux.

Fritz,

I'm trying to catch up in my inbox.  Has anyone reviewed
this patch?

-- 
steve