Bug 59198 - [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[Paul Richard Thomas]

Dear All,

I have tried everything that I know to identify the problem with this
PR.  I would appreciate some help - I feel like I am going crazy with
it!

First of all the original fault is fixed with the attached patch. The
resulting executable, however, segfaults at runtime.  It is, however,
an indication of how strange the problem is.  I have attempted,
without success, to understand how build_constructor can fail to add
the DECL_SIZE field to the FIELD_DECLs. Any ideas?

Even more bizarre are the variants of the testcase that will compile
and run correctly without this patch:

module decays

  implicit none

  interface
    real elemental function iface (arg)
      real, intent(in) :: arg
    end function
  end interface

  type :: decay_term_t
     type(decay_t), pointer :: unstable_product
     integer :: i
  end type

  type :: decay_gen_t
     procedure(iface), nopass, pointer :: obs1_int
     type(decay_term_t), allocatable :: term
  end type

  type :: rng_t
    integer :: i
  end type

  type, extends (decay_gen_t) :: decay_t ! Original type declaration
     class(rng_t), allocatable :: rng ! Make this a pointer - compiles and runs
  end type

!  type :: decay_t ! expand the type extension - compiles and runs
!    procedure(iface), nopass, pointer :: obs1_int
!    type(decay_term_t), allocatable :: term
!    class(rng_t), allocatable :: rng
!  end type

  class(decay_t), allocatable :: object

end



  use decays
  type(decay_t), pointer :: template
  allocate (template)
  allocate (template%rng)
  template%obs1_int => cos
  print *, template%obs1_int (1.570796327)
  allocate (object, source = template)
  print *, object%obs1_int (1.570796327)
end

1) There is nothing fundamentally wrong with the cyclic dependence.
Turn the component 'rng' to a pointer and it compiles and runs OK;
2) On the other hand, if you make this component an allocatable type,
compilation is OK but it segfaults at runtime;
3) More perplexing is the commented out redefinition of 'decay_t'
which compiles and runs correctly. I would have thought that the two
are identical, as far as the backend is concerned.

Does anybody have any suggestions???? I presume that the failuse is in
trans-types.c(gfc_get_derived_type) since the problem looks so similar
to PR24092.

Paul
-------------- next part --------------
Index: gcc/fortran/trans-expr.c
===================================================================
*** gcc/fortran/trans-expr.c	(revision 208048)
--- gcc/fortran/trans-expr.c	(working copy)
*************** gfc_conv_structure (gfc_se * se, gfc_exp
*** 6175,6180 ****
--- 6175,6201 ----
    se->expr = build_constructor (type, v);
    if (init)
      TREE_CONSTANT (se->expr) = 1;
+ 
+   /* Verify that the DECL_SIZE fields have been set so that the
+      constructor is ready for varasm.c(output_constructor_regular_field).
+      TODO: Find out why this is very occasionally necessary.
+      See PR59198.  */
+   type = TREE_TYPE (se->expr);
+   if (TREE_CODE (type) == RECORD_TYPE)
+     {
+       tmp = TYPE_FIELDS (type);
+       while (tmp)
+ 	{
+ 	  if (TREE_CODE (tmp) == FIELD_DECL
+ 	      && DECL_SIZE_UNIT (tmp) == NULL_TREE)
+ 	    {
+ 	      DECL_SIZE (tmp) = TYPE_SIZE (TREE_TYPE (tmp));
+ 	      DECL_SIZE_UNIT (tmp) = TYPE_SIZE_UNIT (TREE_TYPE (tmp));
+ 	    }
+ 	  tmp = TREE_CHAIN (tmp);
+ 	}
+     }
+ 
  }