Bug 42353 - [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...
Summary: [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2009-12-11 22:52 UTC by Harald Anlauf
Modified: 2010-04-18 17:29 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-12-13 21:09:52


Attachments
Reduced demo code (280 bytes, text/plain)
2009-12-11 22:53 UTC, Harald Anlauf
Details
Extended demo code. (739 bytes, text/plain)
2009-12-17 21:09 UTC, Harald Anlauf
Details
Sample code for ICE (877 bytes, text/plain)
2009-12-28 21:44 UTC, Harald Anlauf
Details
A provisional fix for this PR (405 bytes, text/x-patch)
2010-04-16 05:59 UTC, Paul Thomas
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Anlauf 2009-12-11 22:52:49 UTC
Hi there,

the attached code compiles with nagfor but fails to do so with
gfortran 4.5.0 rev. 155016:

gfcbug96.f90:45.33:

end module concrete_inner_product
                                 1
Error: Name 'vtype$vector_class' at (1) is an ambiguous reference to 'vtype$vect
or_class' from module 'concrete_vector'
gfcbug96.f90:45.33:

end module concrete_inner_product
                                 1
Error: Name 'vtype$vector_class' at (1) is an ambiguous reference to 'vtype$vect
or_class' from module 'concrete_vector'
gfcbug96.f90:43.23:

  use concrete_gradient
                       1
Error: The element in the derived type constructor at (1), for pointer component
 '$extends', is DERIVED but should be DERIVED
Comment 1 Harald Anlauf 2009-12-11 22:53:54 UTC
Created attachment 19279 [details]
Reduced demo code
Comment 2 janus 2009-12-11 23:13:39 UTC
Confirmed. Thanks for reporting.
Comment 3 janus 2009-12-13 21:09:51 UTC
One can get rid of this by making the vtypes private:

Index: gcc/fortran/symbol.c
===================================================================
--- gcc/fortran/symbol.c	(revision 155182)
+++ gcc/fortran/symbol.c	(working copy)
@@ -4764,6 +4764,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
 		return NULL;
 	      vtype->refs++;
 	      gfc_set_sym_referenced (vtype);
+	      vtype->attr.access = ACCESS_PRIVATE;
 
 	      /* Add component '$hash'.  */
 	      if (gfc_add_component (vtype, "$hash", &c) == FAILURE)

This patch fixes the error and is regression free.
Comment 4 janus 2009-12-13 21:41:03 UTC
Btw, here is a reduced/modified test case which gives the same error:

module m0
  type :: t
  end type
end module

module m1a
  use m0
  class(t), pointer :: c1
end module

module m1b
  use m0
  class(t), pointer :: c2
end module

module m2
  use m1a
  use m1b
end module
Comment 5 Harald Anlauf 2009-12-16 21:16:14 UTC
(In reply to comment #3)
> One can get rid of this by making the vtypes private:
> 
> Index: gcc/fortran/symbol.c
> ===================================================================
> --- gcc/fortran/symbol.c        (revision 155182)
> +++ gcc/fortran/symbol.c        (working copy)
> @@ -4764,6 +4764,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
>                 return NULL;
>               vtype->refs++;
>               gfc_set_sym_referenced (vtype);
> +             vtype->attr.access = ACCESS_PRIVATE;
> 
>               /* Add component '$hash'.  */
>               if (gfc_add_component (vtype, "$hash", &c) == FAILURE)
> 
> This patch fixes the error and is regression free.

I just tried the patch on my original example and found that this fixes
the first error.  But I am still left with:

gfcbug96.f90:43.23:

  use concrete_gradient
                       1
Error: The element in the derived type constructor at (1), for pointer component '$extends', is DERIVED but should be DERIVED
Comment 6 Harald Anlauf 2009-12-17 21:09:17 UTC
Created attachment 19340 [details]
Extended demo code.

Here's a slightly extended sample of the code where the two
submitted patches still fail with the "ambiguous reference"
error.
Comment 7 janus 2009-12-28 14:15:04 UTC
Here is a reduced version of the test case in comment #6:

module concrete_vector
  type :: trivial_vector_type
  end type
  class(trivial_vector_type), pointer :: this
end module concrete_vector

module concrete_gradient
contains
  subroutine my_to_vector (v)
    use concrete_vector
    class(trivial_vector_type) :: v
    select type (v)
    class is (trivial_vector_type)
    end select
  end subroutine
end module concrete_gradient

module concrete_inner_product
  use concrete_vector
  use concrete_gradient
contains
  real function my_dot_v_v (a)
    class(trivial_vector_type) :: a
    select type (a)
    class is (trivial_vector_type)
    end select
  end function
end module concrete_inner_product
Comment 8 janus 2009-12-28 14:29:20 UTC
Ok, here is a new patch, which fixes all problems reported here so far:

Index: gcc/fortran/symbol.c
===================================================================
--- gcc/fortran/symbol.c	(revision 155486)
+++ gcc/fortran/symbol.c	(working copy)
@@ -4748,6 +4748,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
 	  vtab->attr.target = 1;
 	  vtab->attr.save = SAVE_EXPLICIT;
 	  vtab->attr.vtab = 1;
+	  vtab->attr.access = ACCESS_PRIVATE;
 	  vtab->refs++;
 	  gfc_set_sym_referenced (vtab);
 	  sprintf (name, "vtype$%s", derived->name);
@@ -4764,6 +4765,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
 		return NULL;
 	      vtype->refs++;
 	      gfc_set_sym_referenced (vtype);
+	      vtype->attr.access = ACCESS_PRIVATE;
 
 	      /* Add component '$hash'.  */
 	      if (gfc_add_component (vtype, "$hash", &c) == FAILURE)


Harald, can you check if this version gives you any more trouble? In the meantime I will test it for regressions.
Comment 9 janus 2009-12-28 15:24:04 UTC
(In reply to comment #8)
> In the meantime I will test it for regressions.

Regtest finished successfully.
Comment 10 Harald Anlauf 2009-12-28 18:35:37 UTC
(In reply to comment #8)
> Ok, here is a new patch, which fixes all problems reported here so far:

Janus,

this patch appears OK so far.

(I get a probably unrelated ICE later in the compilation process
of the Fortran project which I am investigating).

Thanks,
Harald
Comment 11 janus 2009-12-28 19:13:07 UTC
(In reply to comment #10)
> this patch appears OK so far.

Great, thanks for checking.


> (I get a probably unrelated ICE later in the compilation process
> of the Fortran project which I am investigating).

Would be great if you could isolate that one and open a new PR for it. If you have trouble reducing it, you can also send your code to me privately, so I can try to help you.

[It's also possibly that we already have a PR for your new ICE.]
Comment 12 Harald Anlauf 2009-12-28 21:44:36 UTC
Created attachment 19404 [details]
Sample code for ICE

Janus,

I have attached a version that results in the following ICE after your patch
was applied.  The error message reads:

gfcbug96c.f90:144:0: internal compiler error: Segmentation fault

[When I use an older trunk version from early December, the ICE appears in
a different place, like

gfcbug96c.f90:102:0: internal compiler error: Segmentation fault

besides the now solved 'vtype$...' problem.]

I have indicated a few lines in the code which can be commented out
to get rid of the ICE.  It looks like another public/private issue.

I am not sure how to figure out whether this ICE is related to a
known issue, maybe PR 41869 or PR 42274 are candidates, or a leftover.
Comment 13 janus 2009-12-28 21:59:12 UTC
(In reply to comment #12)
> I have attached a version that results in the following ICE after your patch
> was applied.  The error message reads:
> 
> gfcbug96c.f90:144:0: internal compiler error: Segmentation fault

Sorry, I'm unable to reproduce this ICE on x86_64-unknown-linux-gnu with the trunk at r155493, neither with the patch in comment #8 nor without.
Comment 14 Harald Anlauf 2009-12-28 22:39:26 UTC
(In reply to comment #13)
> Sorry, I'm unable to reproduce this ICE on x86_64-unknown-linux-gnu with the
> trunk at r155493, neither with the patch in comment #8 nor without.

My mistake, I applied the patch to the same gcc tree (20091210 snapshot)
which I used before.  I updated the Fortran part to the 20091224 snapshot,
applied your patch, and now the code compiles and links successfully!

Sorry for the false alarm!

Harald
Comment 15 janus 2009-12-28 23:13:19 UTC
Subject: Bug 42353

Author: janus
Date: Mon Dec 28 23:13:03 2009
New Revision: 155494

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155494
Log:
gcc/fortran/
2009-12-28 Janus Weil  <janus@gcc.gnu.org>

	PR fortran/42353
	* symbol.c (gfc_find_derived_vtab): Make vtabs and vtypes private.

gcc/testsuite/
2009-12-28  Janus Weil  <janus@gcc.gnu.org>

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

Added:
    trunk/gcc/testsuite/gfortran.dg/class_13.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/symbol.c
    trunk/gcc/testsuite/ChangeLog

Comment 16 janus 2009-12-28 23:16:17 UTC
Fixed with r155494. Closing.
Comment 17 janus 2009-12-30 17:34:59 UTC
Reopening. As reported in http://gcc.gnu.org/ml/fortran/2009-12/msg00215.html, the patch in comment #15 introduced several regressions on the fortran-dev branch.
Comment 18 Jerry DeLisle 2010-01-09 23:11:32 UTC
Regressions on fortran-dev branch fixed.  Committed revision 155778.

Closing.
Comment 19 Dominique d'Humieres 2010-01-09 23:21:47 UTC
> Regressions on fortran-dev branch fixed.

Due to the patch in

http://gcc.gnu.org/ml/fortran/2009-12/msg00232.html

See the entry

2010-01-09  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.

in gcc/fortran/ChangeLog.fortran-dev.
Comment 20 Dominique d'Humieres 2010-01-10 13:33:57 UTC
> Regressions on fortran-dev branch fixed.

This caused pr42680 .
Comment 21 Harald Anlauf 2010-01-18 22:18:07 UTC
(In reply to comment #19)
> > Regressions on fortran-dev branch fixed.
> 
> Due to the patch in
> 
> http://gcc.gnu.org/ml/fortran/2009-12/msg00232.html

Jerry,

is this patch supposed to be complete for fortran-dev?

I still get this failure with the latest fortran-dev on the
original testcase:

gfcbug96.f90:43.23:

  use concrete_gradient
                       1
Error: The element in the derived type constructor at (1), for pointer component '$extends', is DERIVED but should be DERIVED

Should I open a new PR for this one?
Comment 22 Jerry DeLisle 2010-01-19 00:25:45 UTC
Obviously we do not have the original test case added to the testsuite so we can catch these things.  I added gfcbug96d.f90 to the testsuite, thinking it was the same issue as gfcbug96.f90. Lets just reopen this PR, noting that the various cases listed have differing issues and that we need to add test cases for each in the test suite.  
Comment 23 Jerry DeLisle 2010-01-19 02:37:13 UTC
Janus, reassigning to myself.  I think I see a problem in the error checking logic and I have a tentative patch that has regression tested fine.  I want to think a bit about whether I an fixing this correctly.
Comment 24 Jerry DeLisle 2010-01-22 04:30:48 UTC
Un-assigning.  My approach to resolve this by avoiding the error message based on the vaiable name did not work.  I also am getting short on time again.
Comment 25 Paul Thomas 2010-04-16 05:59:24 UTC
Created attachment 20391 [details]
A provisional fix for this PR

This bootstraps and regtests.  I understand why it works but I want to understand why it is necessary; I think that there is an "obvious" fix there.

Paul
Comment 26 janus 2010-04-18 13:13:05 UTC
(In reply to comment #25)
> A provisional fix for this PR

Actually, what's the issue here? At rev. 158483 the fortran-dev testsuite runs cleanly on x86_64-unknown-linux-gnu, and the test cases in this PR (gfcbug96.f90, gfcbug96b.f90 and gfcbug96c.f90) all compile without error. Am I missing something?
Comment 27 Paul Thomas 2010-04-18 13:50:46 UTC
(In reply to comment #26)
> (In reply to comment #25)
> > A provisional fix for this PR
> 
> Actually, what's the issue here? At rev. 158483 the fortran-dev testsuite runs
> cleanly on x86_64-unknown-linux-gnu, and the test cases in this PR
> (gfcbug96.f90, gfcbug96b.f90 and gfcbug96c.f90) all compile without error. Am I
> missing something?
>

Janus,

I am still getting the message:

Error: The element in the derived type constructor at (1), for pointer
component
 '$extends', is DERIVED but should be DERIVED

for gfcbug96.f90.

I'd better check that it's still there when I remove my patch!

Cheers

Paul 

Comment 28 Dominique d'Humieres 2010-04-18 13:55:02 UTC
> I am still getting the message:

Me too with a clean fortran-dev r158481.

Note that the patch in comment #25 fixes it without regression for the test suite and my own tests.
Comment 29 Paul Thomas 2010-04-18 17:24:47 UTC
Subject: Bug 42353

Author: pault
Date: Sun Apr 18 17:24:35 2010
New Revision: 158492

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158492
Log:
2010-04-18  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-18  Paul Thomas  <pault@gcc.gnu.org>

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


Added:
    branches/fortran-dev/gcc/testsuite/gfortran.dg/class_14.f03
Modified:
    branches/fortran-dev/gcc/fortran/resolve.c

Comment 30 Paul Thomas 2010-04-18 17:25:55 UTC
Subject: Bug 42353

Author: pault
Date: Sun Apr 18 17:25:41 2010
New Revision: 158493

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158493
Log:
2010-04-18  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-18  Paul Thomas  <pault@gcc.gnu.org>

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


Modified:
    branches/fortran-dev/gcc/fortran/ChangeLog.fortran-dev
    branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev

Comment 31 Paul Thomas 2010-04-18 17:29:02 UTC
Fixed on fortran-dev.

Thanks for the report, Harald.

Paul
Comment 32 Paul Thomas 2010-04-18 17:29:39 UTC
Hmmm.... better mark it as fixed

Paul
Comment 33 Paul Thomas 2010-04-29 19:11:29 UTC
Subject: Bug 42353

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