[Bug fortran/43896] New: Compiler internal error

[Bug fortran/43896] New: Compiler internal error

[fmartinez at gmv dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

/opt/gfortran/bin/gfortran -c m_rotation_matrix.f03 m_vector.f03 
m_vector.f03: In function ‘rotation_matrix_times_vector’:
m_vector.f03:382:0: internal compiler error: in gfc_conv_variable, at
fortran/trans-expr.c:551
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 
           Summary: Compiler internal error
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: fmartinez at gmv dot com


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

[Bug fortran/43896] Compiler internal error

[fmartinez at gmv dot com]

------- Comment #1 from fmartinez at gmv dot com  2010-04-26 15:35 -------
Created an attachment (id=20493)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20493&action=view)
Just a module, with a type and associated methods. Needed by the one causing
the error.


-- 


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

[Bug fortran/43896] Compiler internal error

[fmartinez at gmv dot com]

------- Comment #2 from fmartinez at gmv dot com  2010-04-26 15:36 -------
Created an attachment (id=20494)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20494&action=view)
The file causing the error during compilation.


-- 


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

[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[janus at gcc dot gnu dot org]

------- Comment #3 from janus at gcc dot gnu dot org  2010-04-26 17:33 -------
Confirmed. The ICE happens with 4.5, trunk and fortran-dev.

Thanks for the report!


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|0000-00-00 00:00:00         |2010-04-26 17:33:45
               date|                            |
            Summary|Compiler internal error     |[OOP] ICE in
                   |                            |gfc_conv_variable, at
                   |                            |fortran/trans-expr.c:551


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

[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2010-04-26 17:38 -------
Confirmed with 4.5.0 and 4.6.0.

At least NAG f95 thinks that the current code is invalid; it writes for the
second file:

Error: m_vector.f03, line 394: Reference via operator * to impure
ROTATION_MATRIX_TIMES_VECTOR from pure ROTATION_MATRIX_TIMES_VECTOR
which is in the following line:

! Compute result
  res%x = rot * right%x

 * * *

The assert fails at gfc_conv_variable for:
  sym = expr->symtree->n.sym;
  if (se->ss != NULL)
    {
      /* Check that something hasn't gone horribly wrong.  */
      gcc_assert (se->ss != gfc_ss_terminator);
      gcc_assert (se->ss->expr == expr); <<<<<<< ICE

 * * *

My old "4.6.0 20100421 fortran-dev revision 158628" fails with another ICE:
ICE in gfc_build_null_descriptor, at fortran/trans-array.c:373


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code


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

[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[janus at gcc dot gnu dot org]

------- Comment #5 from janus at gcc dot gnu dot org  2010-04-26 19:10 -------
(In reply to comment #3)
> The ICE happens with 4.5, trunk and fortran-dev.

Actually this is only half-true. With fortran-dev one already gets an ICE on
the first file, which is different from the one reported in comment #0:

gfortran-dev -c m_rotation_matrix.f03 
f951: internal compiler error: in gfc_build_null_descriptor, at
fortran/trans-array.c:373

So obviously this is a fortran-dev regression.


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-invalid-code         |
            Summary|[OOP] ICE in                |[fortran-dev Regression] ICE
                   |gfc_conv_variable, at       |in gfc_conv_variable, at
                   |fortran/trans-expr.c:551    |fortran/trans-expr.c:551


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

[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[janus at gcc dot gnu dot org]

------- Comment #6 from janus at gcc dot gnu dot org  2010-04-26 19:33 -------
Here is a reduced test case for the fortran-dev failure, which turns out to be
pretty trivial. All it takes is an array-valued TBP (wonder if we don't have
such a thing in the testsuite already):


module m_rotation_matrix

  type t_rotation_matrix
    contains
      procedure :: array => rotation_matrix_array
  end type

contains

  function rotation_matrix_array( rot ) result(array)
    class(t_rotation_matrix) :: rot
    double precision, dimension(3,3)    :: array
  end function

end module


-- 


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

[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[fmartinez at gmv dot com]

------- Comment #7 from fmartinez at gmv dot com  2010-04-26 20:34 -------
Actually both ROTATION_MATRIX_TIMES_VECTOR are pure; the one in m_vector is
elemental, therefore pure, and the one in m_rotation_matrix is pure.
I have changed the one in m_rotation_matrix to ROTATION_MATRIX_TIMES_ARRAY to
remove the names collision and the ICE remains (I guess as expected)
I am a bit surprised about the NAG compiler behaviour.

> Confirmed with 4.5.0 and 4.6.0.
> 
> At least NAG f95 thinks that the current code is invalid; it writes for the
> second file:
> 
> Error: m_vector.f03, line 394: Reference via operator * to impure
> ROTATION_MATRIX_TIMES_VECTOR from pure ROTATION_MATRIX_TIMES_VECTOR
> which is in the following line:
> 
> ! Compute result
>   res%x = rot * right%x
> 
>  * * *
> 
> The assert fails at gfc_conv_variable for:
>   sym = expr->symtree->n.sym;
>   if (se->ss != NULL)
>     {
>       /* Check that something hasn't gone horribly wrong.  */
>       gcc_assert (se->ss != gfc_ss_terminator);
>       gcc_assert (se->ss->expr == expr); <<<<<<< ICE
> 
>  * * *
> 
> My old "4.6.0 20100421 fortran-dev revision 158628" fails with another ICE:
> ICE in gfc_build_null_descriptor, at fortran/trans-array.c:373
> 


-- 


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

[Bug fortran/43896] [fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[janus at gcc dot gnu dot org]

------- Comment #8 from janus at gcc dot gnu dot org  2010-04-26 20:40 -------
Ok, here is a preliminary patch which fixes the fortran-dev problem:

Index: gcc/fortran/symbol.c
===================================================================
--- gcc/fortran/symbol.c        (revision 158741)
+++ gcc/fortran/symbol.c        (working copy)
@@ -4831,8 +4831,7 @@ add_proc_component (gfc_component *c, gfc_symbol *
   /* A static initializer cannot be used here because the specific
      function is not a constant; internal compiler error: in
      output_constant, at varasm.c:4623  */
-  c->initializer = gfc_get_expr ();
-  c->initializer->expr_type = EXPR_NULL;
+  c->initializer = NULL;
 }


@@ -4944,8 +4943,7 @@ copy_vtab_proc_comps (gfc_symbol *declared, gfc_sy
          c->ts.u.derived = cmp->ts.u.derived;
          c->attr.flavor = FL_VARIABLE;
          c->attr.pointer = 1;
-         c->initializer = gfc_get_expr ();
-         c->initializer->expr_type = EXPR_NULL;
+         c->initializer = NULL;
          continue;
        }

@@ -4959,8 +4957,7 @@ copy_vtab_proc_comps (gfc_symbol *declared, gfc_sy
       c->ts.interface = cmp->ts.interface;
       c->attr.untyped = 1;
       c->attr.if_source = IFSRC_IFBODY;
-      c->initializer = gfc_get_expr ();
-      c->initializer->expr_type = EXPR_NULL;
+      c->initializer = NULL;
     }
 }


Will regtest now.


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2010-04-26 17:33:45         |2010-04-26 20:40:53
               date|                            |


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

[Bug fortran/43896] [OOP][fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[burnus at gcc dot gnu dot org]

------- Comment #9 from burnus at gcc dot gnu dot org  2010-04-26 21:00 -------
(In reply to comment #7)
> Actually both ROTATION_MATRIX_TIMES_VECTOR are pure; the one in m_vector is
> elemental, therefore pure, and the one in m_rotation_matrix is pure.
> I have changed the one in m_rotation_matrix to ROTATION_MATRIX_TIMES_ARRAY to
> remove the names collision and the ICE remains (I guess as expected)
> I am a bit surprised about the NAG compiler behaviour.

Same with me - at least that part looks OK; having the same name confuses the
programmer, but it should not confuse the compiler (for generic/operator
resolution) and looks valid (as the specific function is PRIVATE). [NAG f95 =
version 5.1]


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org
            Summary|[fortran-dev Regression] ICE|[OOP][fortran-dev
                   |in gfc_conv_variable, at    |Regression] ICE in
                   |fortran/trans-expr.c:551    |gfc_conv_variable, at
                   |                            |fortran/trans-expr.c:551


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

[Bug fortran/43896] [OOP][fortran-dev Regression] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[janus at gcc dot gnu dot org]

------- Comment #10 from janus at gcc dot gnu dot org  2010-04-27 07:38 -------
Subject: Bug 43896

Author: janus
Date: Tue Apr 27 07:38:06 2010
New Revision: 158767

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158767
Log:
2010-04-27  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/43896
        * symbol.c (add_proc_component,copy_vtab_proc_comps): Remove
        initializers for PPC members of the vtabs.


2010-04-27  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/43896
        * gfortran.dg/class_16.f03: New.

Added:
    branches/fortran-dev/gcc/testsuite/gfortran.dg/class_16.f03
Modified:
    branches/fortran-dev/gcc/fortran/ChangeLog.fortran-dev
    branches/fortran-dev/gcc/fortran/symbol.c
    branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev


-- 


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

[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[janus at gcc dot gnu dot org]

------- Comment #11 from janus at gcc dot gnu dot org  2010-04-27 07:41 -------
The commit in comment #10 fixes the fortran-dev regression, but not the
original problem in comment #0.


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[OOP][fortran-dev           |[OOP] ICE in
                   |Regression] ICE in          |gfc_conv_variable, at
                   |gfc_conv_variable, at       |fortran/trans-expr.c:551
                   |fortran/trans-expr.c:551    |


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

[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[dominiq at lps dot ens dot fr]

------- Comment #12 from dominiq at lps dot ens dot fr  2010-04-27 10:26 -------
> The commit in comment #10 fixes the fortran-dev regression, but not the
> original problem in comment #0.

The original problem in comment #0 is probably a duplicate of pr42051 both
fails with

internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:556

In my tree I have the patch in comment #3 of pr42051 and comment #4 of pr41539
and I don't get the ICE. However I think there is still something wrong as I
get the following link error:

Undefined symbols:
  "_vtab$t_rotation_matrix.2313", referenced from:
      ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
      ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
      ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
      ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
      ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
      ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
      ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
      ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
      ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
      ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
      ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
      ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
      ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
      ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
ld: symbol(s) not found
collect2: ld returned 1 exit status


-- 


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

[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[fmartinez at gmv dot com]

------- Comment #13 from fmartinez at gmv dot com  2010-04-27 12:56 -------
I have not got that far to the linking step. I am converting some code to a
more OOP style.
I have tried to patch my local version but unfrtunately what I have downloaded,
4.5_20100422 and 4.5_20100424, do not seem to match in the symbol.c with the
patch distributed yesterday in the comments. Am I getting the wrong versions of
the source?
Please help.

> > The commit in comment #10 fixes the fortran-dev regression, but not the
> > original problem in comment #0.
> The original problem in comment #0 is probably a duplicate of pr42051 both
> fails with
> internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:556
> In my tree I have the patch in comment #3 of pr42051 and comment #4 of pr41539
> and I don't get the ICE. However I think there is still something wrong as I
> get the following link error:
> Undefined symbols:
>   "_vtab$t_rotation_matrix.2313", referenced from:
>       ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
>       ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
>       ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
>       ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
>       ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
>       ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
>       ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
>       ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
>       ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
>       ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
>       ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
>       ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
>       ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
>       ___m_vector_MOD_rotation_matrix_times_vector in cc5y7koV.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status


-- 


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

[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[burnus at gcc dot gnu dot org]

------- Comment #14 from burnus at gcc dot gnu dot org  2010-04-27 13:30 -------
(In reply to comment #13)
> I have not got that far to the linking step. I am converting some code to a
> more OOP style. I have tried to patch my local version but unfrtunately what
> I have downloaded, 4.5_20100422 and 4.5_20100424, do not seem to match in
> the symbol.c with the patch distributed yesterday in the comments. Am I 
> getting the wrong versions of the source?

Well, there are three development "branches":

* 4.5 ("gcc-4_5-branch", which you seemingly have downloaded): Last stable
  release of GCC, which only sees regression fixes and serious fixes

* 4.6 experimental ("trunk"): The version which will be 4.6.0 in about a year,
  which is continuously being modified.

* "fortran-dev": Based on 4.6, but contains some additional fixes for
  polymorphism/OOP.

The commit in comment 10 was against fortran-dev, which fixed an additional
problem on Fortran-dev, which was revealed with your example. It does not yet
fix the initial problem - neither on Fortran-dev nor on the trunk (i.e. 4.6.0).

In the next few days, the changes from "fortran-dev" will be merged into the
trunk as "fortran-dev" fixes severals OOP-related issues (but not yet yours).

Dominique (comment 12) used a few patches on top of fortran-dev.

I think the simplest is to wait a few days and then use the 4.6 version (not
4.5_...).


-- 


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

[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[janus at gcc dot gnu dot org]

------- Comment #15 from janus at gcc dot gnu dot org  2010-04-27 21:40 -------
I've reduced the test case to the bare minimum required to trigger the ICE:


module m_rotation_matrix

  type t_rotation_matrix
  end type

contains

  function rotation_matrix_times_vector( left ) result(res)
    class(t_rotation_matrix),        intent(in) :: left
    double precision, dimension(3)              :: res
    res = 0
  end function

end module


  use m_rotation_matrix
  type(t_rotation_matrix) :: rot
  print *, rotation_matrix_times_vector (rot )
end


And yes, I agree that it's a duplicate of PR 42051.


-- 


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

[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[pault at gcc dot gnu dot org]

------- Comment #16 from pault at gcc dot gnu dot org  2010-04-29 19:11 -------
Subject: Bug 43896

Author: pault
Date: Thu Apr 29 19:10:48 2010
New Revision: 158910

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158910
Log:
2010-04-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/43896
        * symbol.c (add_proc_component,copy_vtab_proc_comps): Remove
        initializers for PPC members of the vtabs.

2010-04-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/42274
        * symbol.c (add_proc_component,add_proc_comps): Correctly set the 'ppc'
        attribute for all PPC members of the vtypes.
        (copy_vtab_proc_comps): Copy the correct interface.
        * trans.h (gfc_trans_assign_vtab_procs): Modified prototype.
        * trans-expr.c (gfc_trans_assign_vtab_procs): Pass the derived type as
        a dummy argument and make sure all PPC members of the vtab are
        initialized correctly.
        (gfc_conv_derived_to_class,gfc_trans_class_assign): Additional argument
        in call to gfc_trans_assign_vtab_procs.
        * trans-stmt.c (gfc_trans_allocate): Ditto.

2010-04-29  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/43326
        * resolve.c (resolve_typebound_function): Renamed
        resolve_class_compcall.Do all the detection of class references
        here.
        (resolve_typebound_subroutine): resolve_class_typebound_call
        renamed. Otherwise same as resolve_typebound_function.
        (gfc_resolve_expr): Call resolve_typebound_function.
        (resolve_code): Call resolve_typebound_subroutine.

2010-04-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/43492
        * resolve.c (resolve_typebound_generic_call): For CLASS methods
        pass back the specific symtree name, rather than the target
        name.

2010-04-29  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/42353
        * resolve.c (resolve_structure_cons): Make the initializer of
        the vtab component 'extends' the same type as the component.

2010-04-29  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR fortran/42680
        * interface.c (check_interface1): Pass symbol name rather than NULL to
        gfc_compare_interfaces.(gfc_compare_interfaces): Add assert to
        trap MULL. (gfc_compare_derived_types): Revert previous change
        incorporated incorrectly during merge from trunk, r155778.
        * resolve.c (check_generic_tbp_ambiguity): Pass symbol name rather
        than NULL to gfc_compare_interfaces.
        * symbol.c (add_generic_specifics): Likewise.

2010-02-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/42353
        * interface.c (gfc_compare_derived_types): Add condition for vtype.
        * symbol.c (gfc_find_derived_vtab): Sey access to private.
        (gfc_find_derived_vtab): Likewise.
        * module.c (ab_attribute): Add enumerator AB_VTAB.
        (mio_symbol_attribute): Use new attribute, AB_VTAB.
        (check_for_ambiguous): Likewise.

2010-04-29  Paul Thomas  <pault@gcc.gnu.org>
            Janus Weil  <janus@gcc.gnu.org>

        PR fortran/41829
        * trans-expr.c (select_class_proc): Remove function.
        (conv_function_val): Delete reference to previous.
        (gfc_conv_derived_to_class): Add second argument to the call to
        gfc_find_derived_vtab.
        (gfc_conv_structure): Exclude proc_pointer components when
        accessing $data field of class objects.
        (gfc_trans_assign_vtab_procs): New function.
        (gfc_trans_class_assign): Add second argument to the call to
        gfc_find_derived_vtab.
        * symbol.c (gfc_build_class_symbol): Add delayed_vtab arg and
        implement holding off searching for the vptr derived type.
        (add_proc_component): New function.
        (add_proc_comps): New function.
        (add_procs_to_declared_vtab1): New function.
        (copy_vtab_proc_comps): New function.
        (add_procs_to_declared_vtab): New function.
        (void add_generic_specifics): New function.
        (add_generics_to_declared_vtab): New function.
        (gfc_find_derived_vtab): Add second argument to the call to
        gfc_find_derived_vtab. Add the calls to
        add_procs_to_declared_vtab and add_generics_to_declared_vtab.
        * decl.c (build_sym, build_struct): Use new arg in calls to
        gfc_build_class_symbol.
        * gfortran.h : Add vtype bitfield to symbol_attr. Remove the
        definition of struct gfc_class_esym_list. Modify prototypes
        of gfc_build_class_symbol and gfc_find_derived_vtab.
        * trans-stmt.c (gfc_trans_allocate): Add second argument to the
        call to gfc_find_derived_vtab.
        * module.c : Add the vtype attribute.
        * trans.h : Add prototype for gfc_trans_assign_vtab_procs.
        * resolve.c (resolve_typebound_generic_call): Add second arg
        to pass along the generic name for class methods.
        (resolve_typebound_call): The same.
        (resolve_compcall): Use the second arg to carry the generic
        name from the above. Remove the reference to class_esym.
        (check_members, check_class_members, resolve_class_esym,
        hash_value_expr): Remove functions.
        (resolve_class_compcall, resolve_class_typebound_call): Modify
        to use vtable rather than member by member calls.
        (gfc_resolve_expr): Modify second arg in call to
        resolve_compcall.
        (resolve_select_type): Add second arg in call to
        gfc_find_derived_vtab.
        (resolve_code): Add second arg in call resolve_typebound_call.
        (resolve_fl_derived): Exclude vtypes from check for late
        procedure definitions. Likewise for checking of explicit
        interface and checking of pass arg.
        * iresolve.c (gfc_resolve_extends_type_of): Add second arg in
        calls to gfc_find_derived_vtab.
        * match.c (select_type_set_tmp): Use new arg in call to
        gfc_build_class_symbol.
        * trans-decl.c (gfc_get_symbol_decl): Complete vtable if
        necessary.
        * parse.c (endType): Finish incomplete classes.


2010-04-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/42274
        * gfortran.dg/class_16.f03: New test.

2010-04-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/42274
        * gfortran.dg/class_15.f03: New.

2010-04-29  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/43326
        * gfortran.dg/dynamic_dispatch_9.f03: New test.

2010-04-29  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/43492
        * gfortran.dg/generic_22.f03 : New test.

2010-04-29  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/42353
        * gfortran.dg/class_14.f03: New test.

2010-04-29  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR fortran/42680
        * gfortran.dg/interface_32.f90: New test.

2009-04-29  Paul Thomas  <pault@gcc.gnu.org>
            Janus Weil  <janus@gcc.gnu.org>

        PR fortran/41829
        * gfortran.dg/dynamic_dispatch_5.f03 : Change to "run".
        * gfortran.dg/dynamic_dispatch_7.f03 : New test.
        * gfortran.dg/dynamic_dispatch_8.f03 : New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/class_14.f03
    trunk/gcc/testsuite/gfortran.dg/class_15.f03
    trunk/gcc/testsuite/gfortran.dg/class_16.f03
    trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_8.f03
    trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_9.f03
    trunk/gcc/testsuite/gfortran.dg/generic_22.f03
    trunk/gcc/testsuite/gfortran.dg/interface_32.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/interface.c
    trunk/gcc/fortran/iresolve.c
    trunk/gcc/fortran/match.c
    trunk/gcc/fortran/module.c
    trunk/gcc/fortran/parse.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/symbol.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans.h
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_5.f03
    trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_7.f03


-- 


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

[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[fmartinez at gmv dot com]

------- Comment #17 from fmartinez at gmv dot com  2010-05-10 23:22 -------
So it seems tht the bug is not gone. I have tried again with version from May
8th and I still get the problem on line 556.
I tried to submit a comment yesterday but it seems that it failed. Here it goes
again.


-- 

fmartinez at gmv dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fmartinez at gmv dot com


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

[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[janus at gcc dot gnu dot org]

------- Comment #18 from janus at gcc dot gnu dot org  2010-05-16 20:33 -------
(In reply to comment #17)
> So it seems tht the bug is not gone. I have tried again with version from May
> 8th and I still get the problem on line 556.

Yes, the issue is not fixed yet. The commit in comment #16 was just the merging
of the fortran-dev branch to trunk, which did nothing about the ICE.

We'll take care of this soon ...


-- 


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

[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[janus at gcc dot gnu dot org]

------- Comment #19 from janus at gcc dot gnu dot org  2010-06-11 16:46 -------
Subject: Bug 43896

Author: janus
Date: Fri Jun 11 16:45:48 2010
New Revision: 160622

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160622
Log:
2010-06-11  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/42051
        PR fortran/43896
        * trans-expr.c (gfc_conv_derived_to_class): Handle array-valued
        functions with CLASS formal arguments.


2010-06-11  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/42051
        PR fortran/43896
        * gfortran.dg/class_23.f03: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/class_23.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[janus at gcc dot gnu dot org]

------- Comment #20 from janus at gcc dot gnu dot org  2010-06-11 16:50 -------
Fixed with r160622. Closing.


-- 

janus at gcc dot gnu dot org changed:

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


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

[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551

[burnus at gcc dot gnu dot org]

------- Comment #21 from burnus at gcc dot gnu dot org  2010-06-12 07:34 -------
Similarly to PR 41539, I now get linking errors of the kind vtab$...

/tmp/ccd6KJqa.o: In function `__m_vector_MOD_rotation_matrix_times_vector':
test.f90:(.text+0x238b): undefined reference to `vtab$t_rotation_matrix.2317'


-- 


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