The following was found when compiling the Quantum Espresso package, http://www.quantum-espresso.org/. I failed to reduce it further, currently I have: 236 cell_base.f90 56 constants.f90 260 control_flags.f90 119 electrons_base.f90 164 ions_base.f90 5 kind.f90 15 modules.f90 47 parameters.f90 91 recvec.f90 19 test.f90 1012 total The error message shown is: test.f90:13.14: complex c0(n), betae, df,& 1 Error: Symbol 'n' at (1) has no IMPLICIT type test.f90:1.24: subroutine dforceb(c0, i, betae, ipol, bec0, ctabin, gqq, gqqm, qmat, dq2, df) 1 Error: Symbol 'i' at (1) has no IMPLICIT type However, there is: use electrons_base, only: nx => nbspx, n => nbsp, nspin, f [...] integer ipol, i, ctabin
Created attachment 15024 [details] Test files (tar.gz). Use "make" I did not yet pinpoint the failure to a certain commit. However, it works with: 4.2.3 20071030 (prerelease) (SUSE Linux) and fails with both my trunk version 4.3.0 20080125 (experimental) [trunk revision 131818] (GCC) and openSUSE's 4.3.0 20080117 (experimental) [trunk revision 131592] (SUSE Linux)
Paul, do you have an idea? The attached program fails rather strangely. I try to reduce it further, but currently the error disappears as soon as I touch something. Works: 2007-11-23-r130365 Fails: 2007-11-26-r130431 Possibly caused by: r130395 | pault | 2007-11-24 11:17:26 +0100 (Sat, 24 Nov 2007) | 19 lines 2007-11-24 Paul Thomas <pault@gcc.gnu.org> PR fortran/33541 * module.c (find_symtree_for_symbol): Move to new location. (find_symbol): New function. (load_generic_interfaces): Rework completely so that symtrees have the local name and symbols have the use name. Renamed generic interfaces exclude the use of the interface without an ONLY clause (11.3.2). (read_module): Implement 11.3.2 in the same way as for generic interfaces.
(In reply to comment #1) > Created an attachment (id=15024) [edit] > Test files (tar.gz). Use "make" Uggghhh! If the ONLY's i test.f90 are removed, it builds fine or if those USE statments are replaced by USE foobar, with module foobar use electrons_base, only: nx => nbspx, n => nbsp, nspin, f use ions_base, only : nas => nax end module all is OK. When it fails, the symbols i and ipol are BT_UNKNOWN. I am at a bit of a loss to explain this right now. Paul
> If the ONLY's i test.f90 are removed, it builds fine Actually, also removing a single dummy argument (e.g. "df") and it builds fine. I think somewhere the tree might be walked wrongly. The question is only where. Looking at gfc_get_sym_tree, one sees that i and ipol are created twice in ns = gfc_ns_current (= 0x17f7d80). "n" itself appears directly after the symbol "complex" has been created, which means that it has not been added in module.c? Except for "gfc_check_interfaces" gfc_ns_current does not seem to be touched anywhere and that routine resets it. The error message at the end comes via gfc_parse_file's call to "gfc_resolve (gfc_current_ns)".
Subject: Re: [4.3 Regression] Bogus error with USEing modules burnus at gcc dot gnu dot org wrote: > ------- Comment #4 from burnus at gcc dot gnu dot org 2008-01-27 00:14 ------- > >> If the ONLY's i test.f90 are removed, it builds fine >> > Actually, also removing a single dummy argument (e.g. "df") and it builds fine. > I think somewhere the tree might be walked wrongly. The question is only where. > > Looking at gfc_get_sym_tree, one sees that i and ipol are created twice in ns = > gfc_ns_current (= 0x17f7d80). "n" itself appears directly after the symbol > "complex" has been created, which means that it has not been added in module.c? > Except for "gfc_check_interfaces" gfc_ns_current does not seem to be touched > anywhere and that routine resets it. > This is what I am alluding to in the PR - the "hidden." prefix is screwing up the placement of new symbols - i and ipol, which are already present because they are dummies, get missed and new copies added at the type declaration. I have a partial patch working, which causes another regression for reasons that I understand. I'll try to get something out of the door in the next 24 hours. Paul > The error message at the end comes via gfc_parse_file's call to "gfc_resolve > (gfc_current_ns)". > > >
I note that the pigeon carrying my reply to #3 got lost; my subsequent message must therefore be a bit mysterious. Changing the name of the symtree of an unwanted symbol from 'foo' to 'hidden.foo' is completely screwing up walking the symtree and causing duplicate symbols to be generated. I tried to do this when I wrote the patch but simply did not think about the problems that dummy arguments would cause. I have used delete_symtree to partially cure this problem. I need now to mend part of the mechanism introduced by the original patch. It's nearly there:) Paul
Created attachment 15033 [details] A patch for this regression I have just put this on to bootstrap and regtest whilst I sleep. Since it changes nothing in the basic mechanism I believe that it will be OK. In fact, I already tested gfortran.dg/use*.f90 Paul
> Created an attachment (id=15033) [edit] > A patch for this regression > I have just put this on to bootstrap and regtest whilst I sleep. Since it > changes nothing in the basic mechanism I believe that it will be OK. In fact, > I already tested gfortran.dg/use*.f90 I had to change the gfc_undo_symbols part of the patch as gfc_undo_symbols changed completely on the trunk. (Error recovery for COMMON [by Daniel Franke]) Fixing that, it bootstrapped and regtested (-m32/-m64 incl. gomp) successfully on x86-64-linux. I also re-build Quantum ESPRESSO (which was failing before), CP2K, Fleur, Exciting, Octopus, and Abinit successfully. And I've run the Unicomp Fortran 90 Test Suite (Lite) with no new failures. (The current failures seem to be test suit bugs.) Thanks for digging and for the patch.
My tests have not been as exhaustive as the Tobias' ones, but the patch worked as advertised without regression on ppc/intel Darwin9, 32 and 64 bit modes.
Subject: Bug 34975 Author: pault Date: Wed Jan 30 06:56:10 2008 New Revision: 131956 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131956 Log: 2008-01-30 Paul Thomas <pault@gcc.gnu.org> PR fortran/34975 * symbol.c (gfc_delete_symtree, gfc_undo_symbols): Rename delete_symtree to gfc_delete_symtree. * gfortran.h : Add prototype for gfc_delete_symtree. * module.c (load_generic_interfaces): Transfer symbol to a unique symtree and delete old symtree, instead of renaming. (read_module): The rsym and the found symbol are the same, so the found symtree can be deleted. PR fortran/34429 * decl.c (match_char_spec): Remove the constraint on deferred matching of functions and free the length expression. delete_symtree to gfc_delete_symtree. (gfc_match_type_spec): Whitespace. (gfc_match_function_decl): Defer characteristic association for all types except BT_UNKNOWN. * parse.c (decode_specification_statement): Only derived type function matching is delayed to the end of specification. 2008-01-30 Paul Thomas <pault@gcc.gnu.org> PR fortran/34975 * gfortran.dg/use_only_3.f90: New test. * gfortran.dg/use_only_3.inc: Modules for new test. PR fortran/34429 * gfortran.dg/function_charlen_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/function_charlen_2.f90 trunk/gcc/testsuite/gfortran.dg/use_only_3.f90 trunk/gcc/testsuite/gfortran.dg/use_only_3.inc Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/module.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
Fixed on trunk Paul