From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-444620-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 13315 invoked by alias); 22 Feb 2014 13:35:50 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 13262 invoked by uid 48); 22 Feb 2014 13:35:46 -0000
From: "pault at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
Date: Sat, 22 Feb 2014 13:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pault at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-59198-4-6kwLUcszKR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59198-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59198-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-02/txt/msg02377.txt.bz2

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