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
Created attachment 19279 [details] Reduced demo code
Confirmed. Thanks for reporting.
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.
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
(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
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.
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
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.
(In reply to comment #8) > In the meantime I will test it for regressions. Regtest finished successfully.
(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
(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.]
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.
(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.
(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
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
Fixed with r155494. Closing.
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.
Regressions on fortran-dev branch fixed. Committed revision 155778. Closing.
> 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.
> Regressions on fortran-dev branch fixed. This caused pr42680 .
(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?
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.
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.
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.
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
(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?
(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
> 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.
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
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
Fixed on fortran-dev. Thanks for the report, Harald. Paul
Hmmm.... better mark it as fixed Paul
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