The attached source file produces the error with a fresh trunk checkout at r155958. [sfilippo@localhost bugr1]$ gfortran -c psb_s_tools_mod.f90 psb_s_tools_mod.f90:6363:0: internal compiler error: in resolve_typebound_procedure, at fortran/resolve.c:10023 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. [sfilippo@localhost bugr1]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu45 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.5.0 20100116 (experimental) (GCC)
Created attachment 19624 [details] test case Sorry, the test case is a bit lengthy, but I have no time to reduce it further, and I'll be away next week.
As mentioned in http://gcc.gnu.org/ml/fortran/2010-01/msg00075.html the code works with Nag; it is not supposed to behave correctly at runtime under gfortran, not until the vtables from fortran-dev are fixed and merged, but it is supposed to compile correctly, and it did until early December (sorry, I don't remember more precisely).
(In reply to comment #1) > Created an attachment (id=19624) [edit] > test case > > Sorry, the test case is a bit lengthy, but I have no time to reduce it further, > and I'll be away next week. > I got use psb_error_mod 1 Fatal Error: Can't open module file 'psb_error_mod.mod' for reading at (1): No such file or directory
> I got > > use psb_error_mod > 1 > Fatal Error: Can't open module file 'psb_error_mod.mod' for reading at (1): No > such file or directory Me too! After removing all the 'use psb_error_mod' I get the same error (at line 9990) with the fortran-exp branch (r155767) and a segmetation fault with fortran-dev (r155781) and my patched tree.
It is very likely caused by revision : http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html
(Mark as regression (P5); while it was not supported in <4.5, it was working before in 4.5.)
(In reply to comment #4) Sorry, I thought I had taken out all those USE instances (as you guessed they are irrelevant to the bug). Rushing to the airport now...
Here is a reduced test case: module mod1 type :: t1 contains procedure, nopass :: get => my_get end type contains logical function my_get() end function end module module mod2 contains logical function my_get() ! must have the same name as the function in mod1 end function end module module mod3 contains subroutine sub(a) use mod2, only: my_get use mod1, only: t1 ! order of use statements is important type(t1) :: a ! 'a' must be dummy end subroutine end module use mod2, only: my_get use mod3, only: sub ! order of use statements is important end
(In reply to comment #5) > It is very likely caused by revision : > http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html Actually I don't see how this bug could be caused by r152526. That patch was about SELECT TYPE and (ideally) should have no effect on TBPs at all. Also, at first sight, I don't see anything suspicious in the patch. Is there any evidence for the above claim?
(In reply to comment #8) > Here is a reduced test case: > > module mod1 > type :: t1 > contains > procedure, nopass :: get => my_get > end type > contains > logical function my_get() > end function > end module > > module mod2 > contains > logical function my_get() ! must have the same name as the function in > mod1 > end function > end module > > module mod3 > contains > subroutine sub(a) > use mod2, only: my_get > use mod1, only: t1 ! order of use statements is important > type(t1) :: a ! 'a' must be dummy > end subroutine > end module > > > use mod2, only: my_get > use mod3, only: sub ! order of use statements is important > end > I got pr42769-2.f90:14: mod1 1 Error: Unclassifiable statement at (1) pr42769-2.f90:21.26: use mod2, only: my_get 1 Fatal Error: Can't open module file 'mod2.mod' for reading at (1): No such file or directory
(In reply to comment #9) > (In reply to comment #5) > > It is very likely caused by revision : > > http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html > > Actually I don't see how this bug could be caused by r152526. That patch was > about SELECT TYPE and (ideally) should have no effect on TBPs at all. Also, at > first sight, I don't see anything suspicious in the patch. Is there any > evidence for the above claim? With original testcase, removing all "use psb_error_mod", I got [hjl@gnu-34 rrs]$ /export/gnu/import/rrs/152525/usr/bin/gcc -S pr42769.f90 pr42769.f90:1309.36: class is (psb_s_base_sparse_mat) 1 Error: CLASS IS specification at (1) is not yet supported pr42769.f90:1310.22: call b%cp_to_coo(tmp,info) 1 Error: 'cp_to_coo' at (1) is not a member of the 'psb_base_sparse_mat' structure pr42769.f90:2919.36: class is (psb_d_base_sparse_mat) 1 Error: CLASS IS specification at (1) is not yet supported pr42769.f90:2920.22: call b%cp_to_coo(tmp,info) 1 Error: 'cp_to_coo' at (1) is not a member of the 'psb_base_sparse_mat' structure pr42769.f90:3894.24: use psb_d_base_mat_mod 1 Fatal Error: Can't open module file 'psb_d_base_mat_mod.mod' for reading at (1): No such file or directory [hjl@gnu-34 rrs]$ /export/gnu/import/rrs/152525/usr/bin/gcc -v Using built-in specs. COLLECT_GCC=/export/gnu/import/rrs/152525/usr/bin/gcc COLLECT_LTO_WRAPPER=/export/gnu/import/rrs/152525/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../src/configure --prefix=/export/gnu/import/rrs/152525/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --enable-checking --enable-languages=c,c++,fortran --with-ppl=/ --with-cloog=/ --disable-bootstrap Thread model: posix gcc version 4.5.0 20091007 (experimental) [trunk revision 152525] (GCC) [hjl@gnu-34 rrs]$ /export/gnu/import/rrs/152526/usr/bin/gcc -S pr42769.f90 pr42769.f90:1309.36: class is (psb_s_base_sparse_mat) 1 Error: CLASS IS specification at (1) is not yet supported pr42769.f90:180:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. [hjl@gnu-34 rrs]$ /export/gnu/import/rrs/152526/usr/bin/gcc -v Using built-in specs. COLLECT_GCC=/export/gnu/import/rrs/152526/usr/bin/gcc COLLECT_LTO_WRAPPER=/export/gnu/import/rrs/152526/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../src/configure --prefix=/export/gnu/import/rrs/152526/usr --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --enable-checking --enable-languages=c,c++,fortran --with-ppl=/ --with-cloog=/ --disable-bootstrap Thread model: posix gcc version 4.5.0 20091007 (experimental) [trunk revision 152526] (GCC) [hjl@gnu-34 rrs]$
I'd argue this is not even a regression. Sure, the code in comment #1 fails to compile with 4.4 since it contains lots of CLASS declarations. But on comment #8, gfortran 4.4 fails with (almost) the same error: internal compiler error: in resolve_typebound_procedure, at fortran/resolve.c:8505 Salvatore, are you sure this worked with 4.5 at some point, or is this sudden failure rather due to changes in your code? Daniel, since you were the one who implemented most of the TBP stuff in 4.4, could you maybe have a look at this? Seems like there is a problem with equal names in different namespaces ...
(In reply to comment #10) > I got > > pr42769-2.f90:14: > > mod1 > 1 > Error: Unclassifiable statement at (1) The two lines > logical function my_get() ! must have the same name as the function in > mod1 have to be merged in a single one: "...!...the function in mod1".
(In reply to comment #10) > mod1 > 1 > Error: Unclassifiable statement at (1) Sorry, this is due to a wrapped comment in comment #8. Let's try it again: module mod1 type :: t1 contains procedure, nopass :: get => my_get end type contains logical function my_get() end function end module module mod2 contains logical function my_get() end function end module module mod3 contains subroutine sub(a) use mod2, only: my_get use mod1, only: t1 type(t1) :: a end subroutine end module use mod2, only: my_get use mod3, only: sub end This fails with the same error message as comment #1 (with "use psb_error_mod" removed). PLUS, it ICEs also with 4.4. So, no regression.
(In reply to comment #5) > It is very likely caused by revision : > http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00175.html Just for completeness: With trunk r152525 you get the same ICE (with a different line number) on comment #8/#14: internal compiler error: in resolve_typebound_procedure, at fortran/resolve.c:9668 So, r152526 is definitely not the culprit. And this is another hint that this bug was probably always present in 4.5.
I have found a compiled version of the library dating back to Nov. 10, one of the modules has this header: GFORTRAN module version '3' created from psb_base_mod.f90 on Tue Nov 10 13:02:06 2009 MD5:4297c507a682f5457f8eb0404ad04766 -- If you edit this, you'll get what you deserve. I THINK it was trunk. But anyway, an ICE is an ICE, no?
At revision 157277, I no longer see the ICE, but a bunch of errors: pr42769.f90:5063.10: res = a%a%csnmi() 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat) pr42769.f90:4292.30: if (allocated(a%a)) res = a%a%get_nz_row(idx) 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat) pr42769.f90:4279.10: res = a%a%get_size() 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat) pr42769.f90:4265.10: res = a%a%get_nzeros() 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat) pr42769.f90:4075.12: res = a%a%get_fmt() 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat) pr42769.f90:4062.12: res = a%a%sizeof() 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat) pr42769.f90:6279.10: res = a%a%csnmi() 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(psb_s_base_sparse_mat) to CLASS(psb_s_coo_sparse_mat) pr42769.f90:5508.30: if (allocated(a%a)) res = a%a%get_nz_row(idx) 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(psb_s_base_sparse_mat) to CLASS(psb_s_coo_sparse_mat) pr42769.f90:5495.10: res = a%a%get_size() 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(psb_s_base_sparse_mat) to CLASS(psb_s_coo_sparse_mat) pr42769.f90:5481.10: res = a%a%get_nzeros() 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(psb_s_base_sparse_mat) to CLASS(psb_s_coo_sparse_mat) pr42769.f90:5291.12: res = a%a%get_fmt() 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(psb_s_base_sparse_mat) to CLASS(psb_s_coo_sparse_mat) pr42769.f90:5278.12: res = a%a%sizeof() 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(psb_s_base_sparse_mat) to CLASS(psb_s_coo_sparse_mat) pr42769.f90:6329.19: use psb_s_mat_mod 1 Fatal Error: Can't open module file 'psb_s_mat_mod.mod' for reading at (1): No such file or directory I also get similar errors for pr41685: pr41685.f90:374.12: res = a%a%sizeof() 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(s_base_sparse_mat) to CLASS(s_coo_sparse_mat) pr41685.f90:374.12: res = a%a%sizeof() 1 Error: Type mismatch in argument 'a' at (1); passed CLASS(s_base_sparse_mat) to CLASS(s_csr_sparse_mat)
(In reply to comment #17) > At revision 157277, I no longer see the ICE, but a bunch of errors: > > pr42769.f90:5063.10: > > res = a%a%csnmi() > 1 > Error: Type mismatch in argument 'a' at (1); passed > CLASS(psb_d_base_sparse_mat) to CLASS(psb_d_coo_sparse_mat) Dominique, thanks for noticing. This is surely due to the patch for PR43256 that I committed today. Note that this only happens for comment #1, but not for comment #8, which still gives the same error as before. I will open a new PR for this.
(In reply to comment #18) > This is surely due to the patch for PR43256 that I committed today. Sure! > Note that this only happens for comment #1, but not for > comment #8, which still gives the same error as before. Confirmed > I will open a new PR for this. What about the test in pr41685? Reopen, this new PR or another one?
(In reply to comment #18) > I will open a new PR for this. This is now PR 43291.
GCC 4.5.0 is being released. Deferring to 4.5.1.
Janus, is there something left to do here? If yes, are summary and keywords still appropriate?
(In reply to comment #22) > Janus, is there something left to do here? Yes, sure. The ICE has not been fixed yet. With 4.6 trunk (r159368) I still get the same ICE on comment #8/#14: internal compiler error: in resolve_typebound_procedure, at fortran/resolve.c:10304
Here is a somewhat modified version of comment #14, which compiles but produces wrong code: module mod1 type :: t1 contains procedure, nopass :: get => my_get end type contains subroutine my_get() print *,"my_get (mod1)" end subroutine end module module mod2 contains subroutine my_get() ! must have the same name as the function in mod1 print *,"my_get (mod2)" end subroutine end module use mod2 use mod1 ! order of use statements is important type(t1) :: a call a%get() end Output is "my_get (mod2)" while it should be "my_get (mod1)".
This seems to be a module-loading bug. When reading the specific binding of the TBP 'get' from 'mod1' (which happens in module.c, mio_typebound_proc), we expect to get the symbol 'my_get' from 'mod1', but instead we get 'my_get' from 'mod2'. My knowledge of the module-reading code is not sufficient to see where stuff goes wrong. Maybe someone else can?
cf. also PR45271
(In reply to comment #24) > Here is a somewhat modified version of comment #14, which compiles but produces > wrong code: The example in comment #24 contains a statically-resolved TBP call (the pass object is non-polymorphic). One can construct an analogous version with a polymorphic TBP call, which also fails: > module mod1 > type :: t1 > contains > procedure, nopass :: get => my_get > end type > contains > subroutine my_get() > print *,"my_get (mod1)" > end subroutine > end module > > module mod2 > contains > subroutine my_get() ! must have the same name as the function in mod1 > print *,"my_get (mod2)" > end subroutine > end module use mod2 use mod1 ! order of use statements is important class(t1),allocatable :: a allocate(a) call a%get() end
Comment #27 can be fixed by: Index: gcc/fortran/resolve.c =================================================================== --- gcc/fortran/resolve.c (revision 163468) +++ gcc/fortran/resolve.c (working copy) @@ -10937,10 +10937,12 @@ error: stree->n.tb->error = 1; } + static gfc_try resolve_typebound_procedures (gfc_symbol* derived) { int op; + gfc_symbol *vtab; if (!derived->f2k_derived || !derived->f2k_derived->tb_sym_root) return SUCCESS; @@ -10948,6 +10950,9 @@ resolve_typebound_procedures (gfc_symbol* derived) resolve_bindings_derived = derived; resolve_bindings_result = SUCCESS; + /* Make sure the vtab has been generated. */ + vtab = gfc_find_derived_vtab (derived); + if (derived->f2k_derived->tb_sym_root) gfc_traverse_symtree (derived->f2k_derived->tb_sym_root, &resolve_typebound_procedure);
Subject: Bug 42769 Author: janus Date: Sun Aug 29 21:29:38 2010 New Revision: 163631 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163631 Log: 2010-08-29 Janus Weil <janus@gcc.gnu.org> PR fortran/42769 * resolve.c (resolve_structure_cons): For derived types, make sure the type has been resolved. (resolve_typebound_procedures): Make sure the vtab has been generated. 2010-08-29 Janus Weil <janus@gcc.gnu.org> PR fortran/42769 * gfortran.dg/dynamic_dispatch_11.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_11.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
r163631 fixes comment #27, but the other stuff still fails: 1) the original test case (comment #1, ICE) 2) the reduced version (comment #8, ICE) 3) the variant in comment #24 (wrong-code)
(In reply to comment #25) > This seems to be a module-loading bug. When reading the specific binding of the > TBP 'get' from 'mod1' (which happens in module.c, mio_typebound_proc), we > expect to get the symbol 'my_get' from 'mod1', but instead we get 'my_get' from > 'mod2'. > > My knowledge of the module-reading code is not sufficient to see where stuff > goes wrong. Maybe someone else can? This is not a module loading problem I think. It's true that the two `my_get' functions do conflict in the program namespace. One does not need to pass by the program namespace to resolve the typebound call however. That is, the gfc_typebound_proc.u.specific field should be a gfc_symbol, not a gfc_symtree. This way, even if that gfc_symbol is not accessible through a gfc_symtree in the program namespace, it is loaded anyway (and gets a unique symtree but this is an implementation detail) because it is needed in the gfc_typebound_proc struct. That being said, I suppose there is a reason for it to be a gfc_symtree, and not a gfc_symbol.
Created attachment 23460 [details] hack implementing comment 31
One should also look at related bugs PR45836 and pr45900.
The hack in comment 32 compiles correctly comment 24, but rejects the following variant (with the type-bound call in a subroutine) with: use mod2 1 Error: Name 'my_get' at (1) is an ambiguous reference to 'my_get' from module 'mod2' module mod1 type :: t1 contains procedure, nopass :: get => my_get end type contains subroutine my_get() print *,"my_get (mod1)" end subroutine end module module mod2 contains subroutine my_get() ! must have the same name as the function in mod1 print *,"my_get (mod2)" end subroutine end module use mod2 use mod1 ! order of use statements is important type(t1) :: a call call_get contains subroutine call_get call a%get() end subroutine call_get end The reason is that the following code in resolve_call reloads the procedure symbol from the current namespace. This could be disabled with a flag, but it would just make the hack uglier. if (csym && gfc_current_ns->parent && csym->ns != gfc_current_ns) { gfc_symtree *st; gfc_find_sym_tree (csym->name, gfc_current_ns, 1, &st); sym = st ? st->n.sym : NULL; if (sym && csym != sym && sym->ns == gfc_current_ns && sym->attr.flavor == FL_PROCEDURE && sym->attr.contained) { sym->refs++; if (csym->attr.generic) c->symtree->n.sym = sym; else c->symtree = st; csym = c->symtree->n.sym; } }
GCC 4.6.0 is being released, adjusting target milestone.
Author: mikael Date: Sun Jan 6 15:50:09 2013 New Revision: 194949 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194949 Log: PR fortran/42769 PR fortran/45836 PR fortran/45900 * module.c (read_module): Don't reuse local symtree if the associated symbol isn't exactly the one wanted. Don't reuse local symtree if it is ambiguous. * resolve.c (resolve_call): Use symtree's name instead of symbol's to lookup the symtree. PR fortran/42769 PR fortran/45836 PR fortran/45900 * gfortran.dg/use_23.f90: New test. * gfortran.dg/use_24.f90: New test. * gfortran.dg/use_25.f90: New test. * gfortran.dg/use_26.f90: New test. * gfortran.dg/use_27.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/use_23.f90 trunk/gcc/testsuite/gfortran.dg/use_24.f90 trunk/gcc/testsuite/gfortran.dg/use_25.f90 trunk/gcc/testsuite/gfortran.dg/use_26.f90 trunk/gcc/testsuite/gfortran.dg/use_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
Author: mikael Date: Tue Jan 8 19:42:38 2013 New Revision: 195031 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195031 Log: PR fortran/42769 PR fortran/45836 PR fortran/45900 * module.c (read_module): Don't reuse local symtree if the associated symbol isn't exactly the one wanted. Don't reuse local symtree if it is ambiguous. * resolve.c (resolve_call): Use symtree's name instead of symbol's to lookup the symtree. PR fortran/42769 PR fortran/45836 PR fortran/45900 * gfortran.dg/use_23.f90: New test. * gfortran.dg/use_24.f90: New test. * gfortran.dg/use_25.f90: New test. * gfortran.dg/use_26.f90: New test. * gfortran.dg/use_27.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_23.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_24.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_25.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_26.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/use_27.f90 Modified: branches/gcc-4_7-branch/gcc/fortran/ChangeLog branches/gcc-4_7-branch/gcc/fortran/module.c branches/gcc-4_7-branch/gcc/fortran/resolve.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
Author: mikael Date: Tue Jan 8 20:01:49 2013 New Revision: 195032 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195032 Log: PR fortran/42769 PR fortran/45836 PR fortran/45900 * module.c (read_module): Don't reuse local symtree if the associated symbol isn't exactly the one wanted. Don't reuse local symtree if it is ambiguous. * resolve.c (resolve_call): Use symtree's name instead of symbol's to lookup the symtree. PR fortran/42769 PR fortran/45836 PR fortran/45900 * gfortran.dg/use_23.f90: New test. * gfortran.dg/use_24.f90: New test. * gfortran.dg/use_25.f90: New test. * gfortran.dg/use_26.f90: New test. * gfortran.dg/use_27.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_23.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_24.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_25.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_26.f90 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/use_27.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/module.c branches/gcc-4_6-branch/gcc/fortran/resolve.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
Fixed for 4.6.4 4.7.3 4.8.0. Thanks for the bug report.