[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements

[anlauf at gmx dot de]

--- Comment #1 from anlauf at gmx dot de  2010-08-12 19:56 ---
Created an attachment (id=21471)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21471&action=view)
Demo code


-- 


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

[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements

[janus at gcc dot gnu dot org]

--- Comment #2 from janus at gcc dot gnu dot org  2010-08-13 08:22 ---
Confirmed.

-fdump-tree-original shows only one difference when exchanging the use
statements:


--- c1.f90.003t.original2010-08-13 10:05:17.720283742 +0200
+++ c1.f90.003t.original.bug2010-08-13 10:04:53.912784753 +0200
@@ -215,7 +215,7 @@ MAIN__ ()

 if (vtab$trivial_gradient_type.assign == 0B)
   {
-vtab$trivial_gradient_type.assign = my_assign;
+vtab$trivial_gradient_type.assign = (void (*) (struct
class$trivial_gradient_type & restrict, struct class$vector_class & restrict))
my_assign;
   }
 class.8.$vptr = (struct vtype$gradient_class * {ref-all})
&vtab$trivial_gradient_type;
 class.8.$data = (struct gradient_class *) &g_initial;


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2010-08-13 08:22:22
   date||


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

[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements

[janus at gcc dot gnu dot org]

--- Comment #3 from janus at gcc dot gnu dot org  2010-08-13 09:29 ---
Here is a reduced test case:

module abstract_vector
  implicit none
  type, abstract :: vector_class
  contains
procedure(op_assign_v_v), deferred :: assign
  end type vector_class
  abstract interface
subroutine op_assign_v_v(this,v)
  import vector_class
  class(vector_class), intent(inout) :: this
  class(vector_class), intent(in):: v
end subroutine
  end interface
end module abstract_vector

module concrete_vector
  use abstract_vector
  implicit none
  type, extends(vector_class) :: trivial_vector_type
  contains
procedure :: assign => my_assign
  end type
contains
  subroutine my_assign (this,v)
class(trivial_vector_type), intent(inout) :: this
class(vector_class),intent(in):: v
write (*,*) 'Oops in concrete_vector::my_assign'
call abort ()
  end subroutine
end module concrete_vector

module concrete_gradient
  use abstract_vector
  implicit none
  type, extends(vector_class) :: trivial_gradient_type
  contains
procedure :: assign => my_assign
  end type
contains
  subroutine my_assign (this,v)
class(trivial_gradient_type), intent(inout) :: this
class(vector_class),  intent(in):: v
write (*,*) 'concrete_gradient::my_assign'
  end subroutine
end module concrete_gradient

program main
  !--- exchange these two lines to make the code work:
  use concrete_vector! (1)
  use concrete_gradient  ! (2)
  !---
  implicit none
  type(trivial_gradient_type)  :: g_initial
  class(vector_class),  allocatable :: g
  print *, "cg: before g%assign"
  allocate(trivial_gradient_type :: g)
  call g%assign (g_initial)
  print *, "cg: after  g%assign"
end program main


-- 


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

[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements

[janus at gcc dot gnu dot org]

--- Comment #4 from janus at gcc dot gnu dot org  2010-08-13 09:50 ---
The problem is the following:

We have two routines called 'my_assign' (in two different modules). When
initializing the vtabs in the main program, we happen to use the wrong one:

  if (vtab$trivial_gradient_type.assign == 0B)
{
  vtab$trivial_gradient_type.assign = my_assign;
}


Possible solutions:
1) Make sure we use the right symbol from the right module.
2) Do the vtab initialization inside the module that defines the class, i.e.
add a module procedure like 'vtab$trivial_gradient_type$init' which does it,
and call this from the main program. Then there is no name ambiguity.


-- 


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

[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements

[janus at gcc dot gnu dot org]

--- Comment #5 from janus at gcc dot gnu dot org  2010-08-13 12:36 ---

> We have two routines called 'my_assign' (in two different modules). When
> initializing the vtabs in the main program, we happen to use the wrong one:

This is because the 'f2k_derived' namespace of 'trivial_gradient_type' contains
the wrong symbol for 'my_assign'. Apparently the symbols are mixed up when
reading the module files.


The initialization of the vtab happens in gfc_trans_assign_vtab_procs
(trans-expr.c).


-- 


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

[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements

[mikael at gcc dot gnu dot org]

--- Comment #6 from mikael at gcc dot gnu dot org  2010-08-13 14:25 ---
There is code to prevent duplicate names to be imported, but it is bypassed by
vtab and vtype stuff:

in module.c line 4373: 

  /* Exception: Always import vtabs & vtypes.  */
  if (p == NULL && (strcmp (xstrndup (name,5), "vtab$") == 0
|| strcmp (xstrndup (name,6), "vtype$") == 0))
p = name;

  /* Skip symtree nodes not in an ONLY clause, unless there
 is an existing symtree loaded from another USE statement.  */
  if (p == NULL)
{
  st = gfc_find_symtree (gfc_current_ns->sym_root, name);
  if (st != NULL)
info->u.rsym.symtree = st;
  continue;
}


-- 


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

[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements

[janus at gcc dot gnu dot org]

--- Comment #7 from janus at gcc dot gnu dot org  2010-08-13 14:31 ---
(In reply to comment #6)
> There is code to prevent duplicate names to be imported, but it is bypassed by
> vtab and vtype stuff:

This is fine. The problem is not in importing the vtab symbols, but importing
the TBP targets (i.e. "my_assign" in the test case).


-- 


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

[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements

[janus at gcc dot gnu dot org]

--- Comment #8 from janus at gcc dot gnu dot org  2010-08-13 17:23 ---
Actually I think it's a duplicate of PR42769, or at least related.


-- 


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

[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements

[janus at gcc dot gnu dot org]

--- Comment #9 from janus at gcc dot gnu dot org  2010-08-15 20:01 ---
(In reply to comment #4)
> Possible solutions:
> 1) Make sure we use the right symbol from the right module.
> 2) Do the vtab initialization inside the module that defines the class, i.e.
> add a module procedure like 'vtab$trivial_gradient_type$init' which does it,
> and call this from the main program. Then there is no name ambiguity.

3) Do it in the original module (like in #2), but statically via default
initialization. This is definitely the most elegant and efficient way. It
should be possible once PR45290 is implemented.


-- 


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

[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements

[janus at gcc dot gnu dot org]

--- Comment #10 from janus at gcc dot gnu dot org  2010-08-19 13:08 ---
(In reply to comment #9)
> (In reply to comment #4)
> > Possible solutions:
> > 1) Make sure we use the right symbol from the right module.
> > 2) Do the vtab initialization inside the module that defines the class, i.e.
> > add a module procedure like 'vtab$trivial_gradient_type$init' which does it,
> > and call this from the main program. Then there is no name ambiguity.
> 
> 3) Do it in the original module (like in #2), but statically via default
> initialization.

Mine. I'm working on a patch which implements solution #3. It already fixes the
test case, but still has a few regresssions.


-- 

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-08-13 08:22:22 |2010-08-19 13:08:47
   date||


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

[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements

[janus at gcc dot gnu dot org]

--- Comment #11 from janus at gcc dot gnu dot org  2010-08-21 14:51 ---
Subject: Bug 45271

Author: janus
Date: Sat Aug 21 14:50:57 2010
New Revision: 163445

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163445
Log:
2010-08-21  Janus Weil  

PR fortran/45271
PR fortran/45290
* class.c (add_proc_comp): Add static initializer for PPCs.
(add_procs_to_declared_vtab): Modified comment.
* module.c (mio_component): Add argument 'vtype'. Don't read/write the
initializer if the component is part of a vtype.
(mio_component_list): Add argument 'vtype', pass it on to
'mio_component'.
(mio_symbol): Modified call to 'mio_component_list'.
* trans.h (gfc_conv_initializer): Modified prototype.
(gfc_trans_assign_vtab_procs): Removed.
* trans-common.c (create_common): Modified call to
'gfc_conv_initializer'.
* trans-decl.c (gfc_get_symbol_decl,get_proc_pointer_decl,
gfc_emit_parameter_debug_info): Modified call to
'gfc_conv_initializer'.
(build_function_decl): Remove assertion.
* trans-expr.c (gfc_conv_derived_to_class,gfc_trans_class_assign):
Removed call to 'gfc_trans_assign_vtab_procs'.
(gfc_conv_initializer): Add argument 'procptr'.
(gfc_conv_structure): Modified call to 'gfc_conv_initializer'.
(gfc_trans_assign_vtab_procs): Removed.
* trans-stmt.c (gfc_trans_allocate): Removed call to
'gfc_trans_assign_vtab_procs'.


2010-08-21  Janus Weil  

PR fortran/44863
PR fortran/45271
PR fortran/45290
* gfortran.dg/dynamic_dispatch_10.f03: New (PR 44863 comment #1).
* gfortran.dg/pointer_init_5.f90: New (PR 45290 comment #6).
* gfortran.dg/typebound_call_18.f03: New (PR 45271 comment #3).

Added:
trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_10.f03
trunk/gcc/testsuite/gfortran.dg/pointer_init_5.f90
trunk/gcc/testsuite/gfortran.dg/typebound_call_18.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/trans-common.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


-- 


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

[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements

[janus at gcc dot gnu dot org]

--- Comment #12 from janus at gcc dot gnu dot org  2010-08-21 15:00 ---
Fixed with r163445. 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=45271

[Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0