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

["pault at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org

--- Comment #6 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to janus from comment #5)

This one is intriguing! If the ICE is avoided by:
Index: gcc/varasm.c
===================================================================
*** gcc/varasm.c    (revision 208017)
--- gcc/varasm.c    (working copy)
*************** output_constructor_regular_field (oc_loc
*** 4930,4938 ****
        /* ??? This ought to only checked if DECL_SIZE_UNIT is NULL,
       but we cannot do this until the deprecated support for
       initializing zero-length array members is removed.  */
!       if (TREE_CODE (TREE_TYPE (local->field)) == ARRAY_TYPE
        && TYPE_DOMAIN (TREE_TYPE (local->field))
        && ! TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE (local->field))))
      {
        fieldsize = array_size_for_constructor (local->val);
        /* Given a non-empty initialization, this field had
--- 4930,4939 ----
        /* ??? This ought to only checked if DECL_SIZE_UNIT is NULL,
       but we cannot do this until the deprecated support for
       initializing zero-length array members is removed.  */
!       if ((TREE_CODE (TREE_TYPE (local->field)) == ARRAY_TYPE
        && TYPE_DOMAIN (TREE_TYPE (local->field))
        && ! TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE (local->field))))
+       || DECL_SIZE_UNIT (local->field) == NULL_TREE)
      {
        fieldsize = array_size_for_constructor (local->val);
        /* Given a non-empty initialization, this field had


The examples compile.  However,
module decays

  implicit none

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

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

  type :: rng_t
  end type

  type, extends (decay_gen_t) :: decay_t
     class(rng_t), allocatable :: rng
  end type

  class(decay_t), pointer :: object

end

  use decays
  type(decay_t), pointer :: template
  allocate (template)
  allocate (template%rng)
  template%obs1_int => sin
  allocate (object, mold = template)
  object%obs1_int => sin
  print *, object%obs1_int (3.14159/2.)
end

runs and gives the correct result.  If 'mold' is changed to 'source', the
programme segfaults, with:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x41372D in _gfortrani_backtrace at backtrace.c:258
#1  0x402DB0 in _gfortrani_backtrace_handler at compile_options.c:129
#2  0x378B2359AF
#3  0x402658 in __decays_MOD___copy_decays_Decay_t
#4  0x402CAD in MAIN__ at pr59198.f90:0
Segmentation fault (core dumped)

Making the component, 'rng' a pointer restores the expected outcome by
eliminating the call to _def_init_decays_Decay_t. The difference in the code
that this copy procedure produces is:
        if (src->rng._data != 0B)
          {
            dst->rng._data = (struct rng_t *) __builtin_malloc ((unsigned long)
src->rng._vptr->_size);
            src->rng._vptr->_copy (src->rng._data, dst->rng._data);
          }
        else
          {
            dst->rng._data = 0B;
          }

This is as far as I have gone in diagnosing the problem. By the way, though,
even without the patch to varasm.c, changing rng to a pointer fixes the
problem.

I have just noticed that my fix to varasm.c should have gone pear-shaped
because there are no arrays, anywhere to be seen. Stranger and stranger.

Paul