Bug 43896

Summary: [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
Product: gcc Reporter: Fran Martinez Fadrique <ffadrique>
Component: fortranAssignee: janus
Status: RESOLVED FIXED    
Severity: normal CC: burnus, ffadrique, gcc-bugs, janus
Priority: P3 Keywords: ice-on-valid-code
Version: 4.5.0   
Target Milestone: 4.6.0   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2010-04-26 20:40:53
Attachments: Just a module, with a type and associated methods. Needed by the one causing the error.
The file causing the error during compilation.

Description Fran Martinez Fadrique 2010-04-26 15:33:27 UTC
/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.
Comment 1 Fran Martinez Fadrique 2010-04-26 15:35:55 UTC
Created attachment 20493 [details]
Just a module, with a type and associated methods. Needed by the one causing the error.
Comment 2 Fran Martinez Fadrique 2010-04-26 15:36:56 UTC
Created attachment 20494 [details]
The file causing the error during compilation.
Comment 3 janus 2010-04-26 17:33:45 UTC
Confirmed. The ICE happens with 4.5, trunk and fortran-dev.

Thanks for the report!
Comment 4 Tobias Burnus 2010-04-26 17:38:50 UTC
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
Comment 5 janus 2010-04-26 19:10:05 UTC
(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.
Comment 6 janus 2010-04-26 19:33:38 UTC
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
Comment 7 Fran Martinez Fadrique 2010-04-26 20:34:35 UTC
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
> 

Comment 8 janus 2010-04-26 20:40:53 UTC
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.
Comment 9 Tobias Burnus 2010-04-26 21:00:54 UTC
(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]
Comment 10 janus 2010-04-27 07:38:33 UTC
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

Comment 11 janus 2010-04-27 07:41:41 UTC
The commit in comment #10 fixes the fortran-dev regression, but not the original problem in comment #0.
Comment 12 Dominique d'Humieres 2010-04-27 10:26:08 UTC
> 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
Comment 13 Fran Martinez Fadrique 2010-04-27 12:56:43 UTC
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

Comment 14 Tobias Burnus 2010-04-27 13:30:08 UTC
(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_...).
Comment 15 janus 2010-04-27 21:40:42 UTC
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.
Comment 16 Paul Thomas 2010-04-29 19:11:29 UTC
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

Comment 17 Fran Martinez Fadrique 2010-05-10 23:22:15 UTC
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.
Comment 18 janus 2010-05-16 20:33:29 UTC
(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 ...
Comment 19 janus 2010-06-11 16:46:29 UTC
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

Comment 20 janus 2010-06-11 16:50:40 UTC
Fixed with r160622. Closing.
Comment 21 Tobias Burnus 2010-06-12 07:34:56 UTC
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'
Comment 22 janus 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
Comment 23 Dominique d'Humieres 2014-03-28 18:25:08 UTC
*** Bug 60701 has been marked as a duplicate of this bug. ***