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

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

[janus at gcc dot gnu.org]

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

--- Comment #22 from janus at gcc dot gnu.org 2011-08-16 21:22:36 UTC ---
Author: janus
Date: Tue Aug 16 21:22:31 2011
New Revision: 177800

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177800
Log:
2011-08-16  Paul Thomas  <pault@gcc.gnu.org>

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


2011-08-16  Paul Thomas  <pault@gcc.gnu.org>

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

Added:
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/class_23.f03
Modified:
    branches/gcc-4_5-branch/gcc/fortran/ChangeLog
    branches/gcc-4_5-branch/gcc/fortran/trans-expr.c
    branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peter.machon at arcor dot de

--- Comment #23 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 60701 has been marked as a duplicate of this bug. ***

[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

[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

[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 #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

[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

[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

[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

[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

[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

[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

[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

[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] [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