[Patch, Fortran, OOP] PR 44541: wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD

Tobias Burnus burnus@net-b.de
Wed Sep 1 21:28:00 GMT 2010


  Tobias Burnus wrote:
> For my example, the value is set via: resolve_fl_variable -> 
> resolve_fl_variable_derived [...]
> Thus, I really wonder whether the resolve_symbol's version is used at 
> all.

Well, if one comments the block, it fails for 
gfortran.dg/automatic_default_init_1.f90 and 
gfortran.dg/result_default_init_1.f90 (but the test suite is not yet 
finished).

If one looks at the second failure, one sees that one can easily 
construct an example which fails with the current version:

   type A
     integer, pointer:: p => null ()
     integer:: i=3
   end type A
   type(A):: x
   x=f()
   if (associated(x%p) .or. x%i /= 3) call abort ()
contains
   function f() result (fr)
     type(A):: fr
   end function f

As one one has !attr.referenced.

For the former test case: As the automatic array is an array with 
non-init-expression bounds, it does not get initialized via 
build_default_init_expr as:
   if ((sym->attr.dimension && !gfc_is_compile_time_shape (sym->as))
[...]
     return NULL;

While the later apply_default_init does not care about the non-constant 
bounds.

  * * *

I have now filled PR 45489 to track the wrong-code issue.

Tobias





More information about the Fortran mailing list