[Bug fortran/57306] New: ICE on valid with class pointer assignment

[Bug fortran/57306] New: ICE on valid with class pointer assignment

[abensonca at gmail dot com]

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

            Bug ID: 57306
           Summary: ICE on valid with class pointer assignment
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: abensonca at gmail dot com

The following causes an ICE with gfortran 4.9.0 r198983:

module t
  type :: c
  end type c
  type(c), target :: cd
  class(c), public, pointer :: cc => cd
end module t

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools
--enable-languages=c,c++,fortran --disable-multilib
--with-gmp=/home/abenson/Galacticus/Tools
Thread model: posix
gcc version 4.9.0 20130516 (experimental) (GCC) 

$ gfortran -c bug.F90 -o bug.o
bug.F90:7:0: internal compiler error: in gfc_conv_structure, at
fortran/trans-expr.c:6027
   class(c), public, pointer :: cc => cd
 ^
0x5be449 gfc_conv_structure(gfc_se*, gfc_expr*, int)
        ../../gcc-trunk/gcc/fortran/trans-expr.c:6027
0x5be610 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
        ../../gcc-trunk/gcc/fortran/trans-expr.c:5606
0x5a8cd6 gfc_get_symbol_decl(gfc_symbol*)
        ../../gcc-trunk/gcc/fortran/trans-decl.c:1500
0x5aeb02 gfc_create_module_variable
        ../../gcc-trunk/gcc/fortran/trans-decl.c:4144
0x572ed3 do_traverse_symtree
        ../../gcc-trunk/gcc/fortran/symbol.c:3571
0x5aef52 gfc_generate_module_vars(gfc_namespace*)
        ../../gcc-trunk/gcc/fortran/trans-decl.c:4543
0x588ec1 gfc_generate_module_code(gfc_namespace*)
        ../../gcc-trunk/gcc/fortran/trans.c:1738
0x547687 translate_all_program_units
        ../../gcc-trunk/gcc/fortran/parse.c:4456
0x547687 gfc_parse_file()
        ../../gcc-trunk/gcc/fortran/parse.c:4666
0x583a25 gfc_be_parse_file
        ../../gcc-trunk/gcc/fortran/f95-lang.c:189
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug fortran/57306] [OOP] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-05-16
                 CC|                            |janus at gcc dot gnu.org
            Summary|ICE on valid with class     |[OOP] ICE on valid with
                   |pointer assignment          |class pointer
                   |                            |initialization
     Ever confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed with 4.7, 4.8 and trunk.

[Bug fortran/57306] [OOP] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
The following patch seems to fix it ...


Index: gcc/fortran/trans-decl.c
===================================================================
--- gcc/fortran/trans-decl.c    (revision 201253)
+++ gcc/fortran/trans-decl.c    (working copy)
@@ -1491,14 +1491,15 @@ gfc_get_symbol_decl (gfc_symbol * sym)
      SAVE is specified otherwise they need to be reinitialized
      every time the procedure is entered. The TREE_STATIC is
      in this case due to -fmax-stack-var-size=.  */
+      bool ptr = sym->attr.pointer || sym->attr.allocatable
+        || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->attr.pointer);
+                          
       DECL_INITIAL (decl) = gfc_conv_initializer (sym->value, &sym->ts,
                           TREE_TYPE (decl),
                           sym->attr.dimension
                           || (sym->attr.codimension
                               && sym->attr.allocatable),
-                          sym->attr.pointer
-                          || sym->attr.allocatable,
-                          sym->attr.proc_pointer);
+                          ptr, sym->attr.proc_pointer);
     }

   if (!TREE_STATIC (decl)

[Bug fortran/57306] [OOP] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> The following patch seems to fix it ...

... but unfortunately ICEs on a number of tests, e.g. class_{13,18,33,34} and
others.

[Bug fortran/57306] [OOP] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
Here is an enhanced patch which regtests cleanly:


Index: gcc/fortran/trans-decl.c
===================================================================
--- gcc/fortran/trans-decl.c    (revision 201253)
+++ gcc/fortran/trans-decl.c    (working copy)
@@ -1491,14 +1491,16 @@ gfc_get_symbol_decl (gfc_symbol * sym)
      SAVE is specified otherwise they need to be reinitialized
      every time the procedure is entered. The TREE_STATIC is
      in this case due to -fmax-stack-var-size=.  */
+      bool ptr = sym->attr.pointer || sym->attr.allocatable
+         || (sym->ts.type == BT_CLASS
+             && CLASS_DATA (sym)->attr.class_pointer);
+                          
       DECL_INITIAL (decl) = gfc_conv_initializer (sym->value, &sym->ts,
                           TREE_TYPE (decl),
                           sym->attr.dimension
                           || (sym->attr.codimension
                               && sym->attr.allocatable),
-                          sym->attr.pointer
-                          || sym->attr.allocatable,
-                          sym->attr.proc_pointer);
+                          ptr, sym->attr.proc_pointer);
     }

   if (!TREE_STATIC (decl)
Index: gcc/fortran/trans-expr.c
===================================================================
--- gcc/fortran/trans-expr.c    (revision 201253)
+++ gcc/fortran/trans-expr.c    (working copy)
@@ -5664,7 +5664,18 @@ gfc_conv_initializer (gfc_expr * expr, gfc_typespe
   else if (pointer || procptr)
     {
       if (!expr || expr->expr_type == EXPR_NULL)
-    return fold_convert (type, null_pointer_node);
+    {
+      if (ts->type == BT_CLASS)
+        {
+          gfc_init_se (&se, NULL);
+          gfc_conv_structure (&se, gfc_class_null_initializer(ts, expr), 1);
+          gcc_assert (TREE_CODE (se.expr) == CONSTRUCTOR);
+          TREE_STATIC (se.expr) = 1;
+          return se.expr;
+        }
+      else
+        return fold_convert (type, null_pointer_node);
+    }
       else
     {
       gfc_init_se (&se, NULL);

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[OOP] ICE on valid with     |[OOP] [F08] ICE on valid
                   |class pointer               |with class pointer
                   |initialization              |initialization

--- Comment #5 from janus at gcc dot gnu.org ---
Btw, pointer init is an F08 feature ...

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
An updated patch was posted here:

http://gcc.gnu.org/ml/fortran/2013-07/msg00135.html

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
Here is a reduced version of the test case from
http://gcc.gnu.org/ml/fortran/2013-07/msg00103.html, which for some reason
still ICEs:


  type :: c
  end type c

  type(c), target :: x
  class(c), pointer :: px => x

  if (.not. associated(px)) call abort()
end 



internal compiler error: in expand_expr_real_1, at expr.c:9361
 end 
 ^
0x764cdd expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
        /home/janus/gcc49/trunk/gcc/expr.c:9356
0x76b7b7 expand_expr
        /home/janus/gcc49/trunk/gcc/expr.h:444
0x76b7b7 expand_expr_addr_expr_1
        /home/janus/gcc49/trunk/gcc/expr.c:7587
0x762a59 expand_expr_addr_expr
        /home/janus/gcc49/trunk/gcc/expr.c:7710
0x762a59 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
        /home/janus/gcc49/trunk/gcc/expr.c:10451
0xabcfca expand_expr
        /home/janus/gcc49/trunk/gcc/expr.h:444
0xabcfca output_constant
        /home/janus/gcc49/trunk/gcc/varasm.c:4665
0xabcfca output_constant(tree_node*, unsigned long, unsigned int)
        /home/janus/gcc49/trunk/gcc/varasm.c:4566
0xabdb4b output_constructor_regular_field
        /home/janus/gcc49/trunk/gcc/varasm.c:4912
0xabdb4b output_constructor
        /home/janus/gcc49/trunk/gcc/varasm.c:5191
0xac1981 assemble_variable(tree_node*, int, int, int)
        /home/janus/gcc49/trunk/gcc/varasm.c:2113
0xac2259 varpool_assemble_decl(varpool_node*)
        /home/janus/gcc49/trunk/gcc/varpool.c:347
0x6d9f12 output_in_order
        /home/janus/gcc49/trunk/gcc/cgraphunit.c:1788
0x6d9f12 compile()
        /home/janus/gcc49/trunk/gcc/cgraphunit.c:2024
0x6da184 finalize_compilation_unit()
        /home/janus/gcc49/trunk/gcc/cgraphunit.c:2106
0x82b04c write_global_declarations()
        /home/janus/gcc49/trunk/gcc/langhooks.c:322
0x5f82bf gfc_write_global_declarations
        /home/janus/gcc49/trunk/gcc/fortran/f95-lang.c:263

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to janus from comment #7)
> Here is a reduced version of the test case from
> http://gcc.gnu.org/ml/fortran/2013-07/msg00103.html, which for some reason
> still ICEs:
> 
> 
>   type :: c
>   end type c
> 
>   type(c), target :: x
>   class(c), pointer :: px => x
> 
>   if (.not. associated(px)) call abort()
> end 

Putting this inside a subroutine, one gets:

  class(c), pointer :: px => x
                              1
Error: Pointer initialization target at (1) must have the SAVE attribute


Giving 'x' the SAVE attribute makes both versions compile without error. I
guess the original version is still valid, since 'x' should implicitly get the
SAVE attribute [1]. However, without the explicit SAVE declaration, it is not
shown as 'static' in the dump.


[1] F08, section 5.3.16: "A variable, common block, or procedure pointer
declared in the scoping unit of a main program, module, or submodule implicitly
has the SAVE attribute, which may be confirmed by explicit specification."

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to janus from comment #8)
> Giving 'x' the SAVE attribute makes both versions compile without error. I
> guess the original version is still valid, since 'x' should implicitly get
> the SAVE attribute [1]. However, without the explicit SAVE declaration, it
> is not shown as 'static' in the dump.

Problem is: We currently don't make variables in the main program SAVE_IMPLICT
yet.

There is a patch in PR 55207 comment 3 which does this. Applying it (in
addition to the patch from comment 6) makes the ICE in comment 7 go away.
Unfortunately it had a couple of regressions, see in particular PR 55207
comment 6.

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> ---
> Putting this inside a subroutine, one gets:
> 
>   class(c), pointer :: px => x
>                               1
> Error: Pointer initialization target at (1) must have the SAVE attribute

That sounds like a bug:

"Explicit initialization of a variable that is not in a common block implies
the SAVE attribute, which may be confirmed by explicit specification." (5.2.3
Initialization, F2008)

And "px" is clearly initialized - see R505 and "The appearance of
initialization in an entity-decl for an entity without the PARAMETER attribute
speci\fes that
the entity is a variable with explicit initialization."
>From gcc-bugs-return-427134-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 01 21:40:40 2013
Return-Path: <gcc-bugs-return-427134-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22161 invoked by alias); 1 Aug 2013 21:40:39 -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
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 22068 invoked by uid 48); 1 Aug 2013 21:40:36 -0000
From: "janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/55207] Automatic deallocation of variables declared in the main program
Date: Thu, 01 Aug 2013 21:40: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.8.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: janus at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-55207-4-qxKUZqnPz1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55207-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55207-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: 2013-08/txt/msg00058.txt.bz2
Content-length: 498

http://gcc.gnu.org/bugzilla/show_bug.cgi?idU207

--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #11)
>
> +  if ((gfc_current_state () == COMP_MODULE
> +       || gfc_current_state () == COMP_PROGRAM)
>
> I haven't tried the patch, but does it work correctly with BLOCK? (It might
> well be valid.)

Without actually trying it: I would say it should work, since a BLOCK construct
would imply COMP_BLOCK here, so that the save attribute is not set ...

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #10)
> > Putting this inside a subroutine, one gets:
> > 
> >   class(c), pointer :: px => x
> >                               1
> > Error: Pointer initialization target at (1) must have the SAVE attribute
> 
> That sounds like a bug:

Ah, good point. Clearly we need to make sure that px gets marked as
SAVE_IMPLICIT here! Somehow I missed this on the first glance ...

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #10)
> > Putting this inside a subroutine, one gets:
> > 
> >   class(c), pointer :: px => x
> >                               1
> > Error: Pointer initialization target at (1) must have the SAVE attribute
> 
> That sounds like a bug:
> 
> "Explicit initialization of a variable that is not in a common block implies
> the SAVE attribute, which may be confirmed by explicit specification."
> (5.2.3 Initialization, F2008)
> 
> And "px" is clearly initialized

Oh, wait: The error is about the *target*, not the pointer. Therefore I think
it's indeed correct and there is no bug!

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

--- Comment #13 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue Aug  6 08:20:17 2013
New Revision: 201521

URL: http://gcc.gnu.org/viewcvs?rev=201521&root=gcc&view=rev
Log:
2013-08-06  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/57306
    * class.c (gfc_class_null_initializer): Rename to
    'gfc_class_initializer'. Treat non-NULL init-exprs.
    * gfortran.h (gfc_class_null_initializer): Update prototype.
    * trans-decl.c (gfc_get_symbol_decl): Treat class variables.
    * trans-expr.c (gfc_conv_initializer): Ditto.
    (gfc_trans_subcomponent_assign): Renamed gfc_class_null_initializer.

2013-08-06  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/57306
    * gfortran.dg/pointer_init_8.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/pointer_init_8.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/class.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #14 from janus at gcc dot gnu.org ---
r201521 basically fixes this PR (the remaining problem of comment 7 will be
tracked by PR 55207). Closing.

[Bug fortran/57306] [OOP] [F08] ICE on valid with class pointer initialization

[abensonca at gmail dot com]

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

--- Comment #15 from Andrew Benson <abensonca at gmail dot com> ---
Thanks for fixing!