This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, fortran] PR29216 & PR29394 - Default initialization for fucntion results and intent OUT automatic arrays.

Mostly your patch looks OK, and I like your approach to the problem, but
one thing remained a bit unclear to me:

On Tue, Oct 17, 2006 at 04:01:47PM +0200, THOMAS Paul Richard 169137 wrote:
> :ADDPATCH fortran:
> This patch fixes two places where default initializers were not being applied but should
> be; function results and intent OUT automatic arrays. If any exist, it will also catch
I'm not sure if I follow you here -- neither of the bugs this patch is
fixing are concerned about anything that has intent OUT (or intent
anything else).  Intent OUT variables with default initializers need to
be initialized of course, but that works already (thanks to some code in
trans-expr.c (gfc_conv_function_call), around line 2033.  More on this

> 2006-10-17  Paul Thomas <>
> 	PR fortran/29216
> 	PR fortran/29314
> 	* gfortran.h : Add EXEC_INIT_ASSIGN.
> 	* dump-parse-tree.c (gfc_show_code_node): The same.
> 	* trans-openmp.c gfc_trans_omp_array_reduction): Set new
> 	for gfc_trans_assignment false.
> 	* trans-stmt.c (gfc_trans_forall_1): The same.
> 	* trans-stmt.h : Add prototype for gfc_trans_init_assign.
> 	* trans.c (gfc_trans_code): Implement EXEC_INIT_ASSIGN.
> 	* trans.h : Add new boolean argument to the prototype of
> 	gfc_trans_assignment.
> 	* resolve.c (resolve_allocate_exp): Replace EXEC_ASSIGN by
> 	(resolve_code): EXEC_INIT_ASSIGN does not need resolution.
> 	(apply_default_init): New function.
> 	(resolve_symbol): Call it for derived type function results
> 	and for INTENT_OUT dummies.
> 	* st.c (gfc_free_statement): Include EXEC_INIT_ASSIGN.

Here's no mention of the changes to trans-expr.c

  static try
*************** resolve_symbol (gfc_symbol * sym)
*** 5960,5965 ****
--- 6032,6051 ----
            && (sym->ns->proc_name == NULL
                || sym->ns->proc_name->attr.flavor != FL_MODULE)))
      gfc_error ("Threadprivate at %L isn't SAVEd", &sym->declared_at);
+   /* If we have come this far we can apply default-initializers as
+      described in 14.7.5.  */
+   if (sym->ts.type == BT_DERIVED && sym->ns == gfc_current_ns && !sym->value)
+     {
+       symbol_attribute *a = &sym->attr;
+       if ((!a->save && !a->dummy && !a->use_assoc && !a->pointer
+ 		&& !a->allocatable && !a->alloc_comp && !a->in_common
+ 		&& !(a->function && sym != sym->result))
+ 	     ||
+ 	  (a->dummy && a->intent == INTENT_OUT && !a->alloc_comp))
+ 	apply_default_init (sym);
+     }

This seems to be intended to intialize intent OUT variables, but when I
replaced the line 

        apply_default_init (sym);

above with 

        fprintf(stderr,"Calling apply_default_init\n");
        apply_default_init (sym);

and compiled this little program
module foo

    type :: t
        integer :: a = 6
    end type t


    subroutine mu(c)
        type(t), intent(out) :: c(:)
    end subroutine mu

end module foo

program bar

    use foo

    type(t) :: a(2)

    a%a = 5
    call mu(a)
    print *, a%a

end program bar
"Calling apply_default_init" was NOT printed, which indicates that
apply_default_init() isn't being called here (I haven't checked why).
The reason why it works is the previously mentioned code in trans-expr.c

Now, however, I like your approach and think that initialization of
intent OUT _should_ be done using apply_default_init() instead using of
the current approach.  But that's not what's happening now.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]