This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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, OOP] PR 44541: wrong code for polymorphic variable with INTENT(OUT)/Alloc w/ MOLD


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




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