* [Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
2010-08-12 19:55 [Bug fortran/45271] New: [OOP] Polymorphic code breaks when changing order of USE statements anlauf at gmx dot de
@ 2010-08-12 19:56 ` anlauf at gmx dot de
2010-08-13 8:22 ` janus at gcc dot gnu dot org
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: anlauf at gmx dot de @ 2010-08-12 19:56 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
2010-08-12 19:55 [Bug fortran/45271] New: [OOP] Polymorphic code breaks when changing order of USE statements anlauf at gmx dot de
2010-08-12 19:56 ` [Bug fortran/45271] " anlauf at gmx dot de
@ 2010-08-13 8:22 ` janus at gcc dot gnu dot org
2010-08-13 9:30 ` janus at gcc dot gnu dot org
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-13 8:22 UTC (permalink / raw)
To: gcc-bugs
------- 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.original 2010-08-13 10:05:17.720283742 +0200
+++ c1.f90.003t.original.bug 2010-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 (*<T4a1>) (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|0000-00-00 00:00:00 |2010-08-13 08:22:22
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
2010-08-12 19:55 [Bug fortran/45271] New: [OOP] Polymorphic code breaks when changing order of USE statements anlauf at gmx dot de
2010-08-12 19:56 ` [Bug fortran/45271] " anlauf at gmx dot de
2010-08-13 8:22 ` janus at gcc dot gnu dot org
@ 2010-08-13 9:30 ` janus at gcc dot gnu dot org
2010-08-13 9:50 ` janus at gcc dot gnu dot org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-13 9:30 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
2010-08-12 19:55 [Bug fortran/45271] New: [OOP] Polymorphic code breaks when changing order of USE statements anlauf at gmx dot de
` (2 preceding siblings ...)
2010-08-13 9:30 ` janus at gcc dot gnu dot org
@ 2010-08-13 9:50 ` janus at gcc dot gnu dot org
2010-08-13 12:36 ` janus at gcc dot gnu dot org
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-13 9:50 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
2010-08-12 19:55 [Bug fortran/45271] New: [OOP] Polymorphic code breaks when changing order of USE statements anlauf at gmx dot de
` (3 preceding siblings ...)
2010-08-13 9:50 ` janus at gcc dot gnu dot org
@ 2010-08-13 12:36 ` janus at gcc dot gnu dot org
2010-08-13 14:25 ` mikael at gcc dot gnu dot org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-13 12:36 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
2010-08-12 19:55 [Bug fortran/45271] New: [OOP] Polymorphic code breaks when changing order of USE statements anlauf at gmx dot de
` (4 preceding siblings ...)
2010-08-13 12:36 ` janus at gcc dot gnu dot org
@ 2010-08-13 14:25 ` mikael at gcc dot gnu dot org
2010-08-13 14:31 ` janus at gcc dot gnu dot org
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: mikael at gcc dot gnu dot org @ 2010-08-13 14:25 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
2010-08-12 19:55 [Bug fortran/45271] New: [OOP] Polymorphic code breaks when changing order of USE statements anlauf at gmx dot de
` (5 preceding siblings ...)
2010-08-13 14:25 ` mikael at gcc dot gnu dot org
@ 2010-08-13 14:31 ` janus at gcc dot gnu dot org
2010-08-13 17:23 ` janus at gcc dot gnu dot org
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-13 14:31 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
2010-08-12 19:55 [Bug fortran/45271] New: [OOP] Polymorphic code breaks when changing order of USE statements anlauf at gmx dot de
` (6 preceding siblings ...)
2010-08-13 14:31 ` janus at gcc dot gnu dot org
@ 2010-08-13 17:23 ` janus at gcc dot gnu dot org
2010-08-15 20:01 ` janus at gcc dot gnu dot org
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-13 17:23 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
2010-08-12 19:55 [Bug fortran/45271] New: [OOP] Polymorphic code breaks when changing order of USE statements anlauf at gmx dot de
` (7 preceding siblings ...)
2010-08-13 17:23 ` janus at gcc dot gnu dot org
@ 2010-08-15 20:01 ` janus at gcc dot gnu dot org
2010-08-19 13:09 ` janus at gcc dot gnu dot org
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-15 20:01 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
2010-08-12 19:55 [Bug fortran/45271] New: [OOP] Polymorphic code breaks when changing order of USE statements anlauf at gmx dot de
` (8 preceding siblings ...)
2010-08-15 20:01 ` janus at gcc dot gnu dot org
@ 2010-08-19 13:09 ` janus at gcc dot gnu dot org
2010-08-21 14:51 ` janus at gcc dot gnu dot org
2010-08-21 15:00 ` janus at gcc dot gnu dot org
11 siblings, 0 replies; 13+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-19 13:09 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
2010-08-12 19:55 [Bug fortran/45271] New: [OOP] Polymorphic code breaks when changing order of USE statements anlauf at gmx dot de
` (9 preceding siblings ...)
2010-08-19 13:09 ` janus at gcc dot gnu dot org
@ 2010-08-21 14:51 ` janus at gcc dot gnu dot org
2010-08-21 15:00 ` janus at gcc dot gnu dot org
11 siblings, 0 replies; 13+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-21 14:51 UTC (permalink / raw)
To: gcc-bugs
------- 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 <janus@gcc.gnu.org>
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 <janus@gcc.gnu.org>
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug fortran/45271] [OOP] Polymorphic code breaks when changing order of USE statements
2010-08-12 19:55 [Bug fortran/45271] New: [OOP] Polymorphic code breaks when changing order of USE statements anlauf at gmx dot de
` (10 preceding siblings ...)
2010-08-21 14:51 ` janus at gcc dot gnu dot org
@ 2010-08-21 15:00 ` janus at gcc dot gnu dot org
11 siblings, 0 replies; 13+ messages in thread
From: janus at gcc dot gnu dot org @ 2010-08-21 15:00 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 13+ messages in thread