When I try to build a program that uses a module that I created with a comment on the third line, it tries to interpret the comment and gives the error: $ gfortran llnew.f90 -o llnew Fatal Error: Reading module numberlists at line 3 column 4: Bad name Line 3 should be just a comment. I'm attaching the llnew.f90 code and the numberlists.mod files. This occurs on Debian testing with the current version. In the current version that is built for windows (GNU Fortran 95 (GCC 4.1.0 20050902 (experimental))), it gives an ICE: Fatal Error: Reading module number_lists at line 3 column 4: Bad name gfortran: Internal error: Aborted (program f951) Please submit a full bug report. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Created attachment 9996 [details] no errors in this source, but it uses the module
Created attachment 9997 [details] Error where line 4 is a comment
Can you attach the .f90 file which contains the module numberlists?
(In reply to comment #3) > Can you attach the .f90 file which contains the module numberlists? > You're too quick for me. I was in the process of attaching it. It's there now.
Oh, I noticed what you did now. You are not compiling the module but have it named numberlists.mod. Change the filename of numberlists.mod to numberlists.f90. And try: gfortran numberlists.f90 llnew.f90 -o llnew That should work.
Perhaps a better error message than Fatal Error: Reading module numberlists at line 3 column 4: Bad name would be Fatal Error: Reading module numberlists at line 3 column 4: Bad name (perhaps not a compiled module file)
Even better would be if gfortran recognized that the file was not a valid mod at all and just states "Module file invalid". Of course users have to know they do not edit 'mod' files, only source files.
Created attachment 12388 [details] A fix for this PR This checks for the presence of "GFORTRAN module" as the first utterances in the .mod file. The error message on this not being so is evident in the patch and is even understandable. *sigh* Paul
Paul, I read the patch, and think that you can commit it. gfortran certainly can't recover for a mangled module.
Subject: Bug 24398 Author: pault Date: Fri Oct 13 12:51:07 2006 New Revision: 117692 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117692 Log: 2006-10-13 Paul Thomas <pault@gcc.gnu.org> PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29422 * resolve.c (resolve_transfer): Test functions for suitability for IO, as well as variables. PR fortran/29428 * trans-expr.c (gfc_trans_scalar_assign): Remove nullify of rhs expression. 2006-10-13 Paul Thomas <pault@gcc.gnu.org> PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29422 * gfortran.dg/alloc_comp_constraint_4.f90: New test. PR fortran/29428 * gfortran.dg/alloc_comp_assign_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_5.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_4.f90 trunk/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 trunk/gcc/testsuite/gfortran.dg/implicit_9.f90 trunk/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 trunk/gcc/testsuite/gfortran.dg/namelist_25.f90 trunk/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/implicit_actual.f90
Fixed in trunk Paul
Subject: Bug 24398 Author: pault Date: Mon Nov 6 17:18:03 2006 New Revision: 118522 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118522 Log: 2006-11-06 Paul Thomas <pault@gcc.gnu.org> PR fortran/29373 * decl.c (get_proc_name, gfc_match_function_decl): Add attr.implicit_type to conditions that throw error for existing explicit interface and that allow new type- spec to be applied. PR fortran/29407 * resolve.c (resolve_fl_namelist): Do not check for namelist/procedure conflict, if the symbol corresponds to a good local variable declaration. PR fortran/27701 * decl.c (get_proc_name): Replace the detection of a declared procedure by the presence of a formal argument list by the attributes of the symbol and the presence of an explicit interface. PR fortran/29232 * resolve.c (resolve_fl_variable): See if the host association of a derived type is blocked by the presence of another type I object in the current namespace. PR fortran/29364 * resolve.c (resolve_fl_derived): Check for the presence of the derived type for a derived type component. PR fortran/24398 * module.c (gfc_use_module): Check that the first words in a module file are 'GFORTRAN module'. PR fortran/29115 * resolve.c (resolve_structure_cons): It is an error if the pointer component elements of a derived type constructor are not pointer or target. PR fortran/29211 * trans-stmt.c (generate_loop_for_temp_to_lhs, generate_loop_for_rhs_to_temp): Provide a string length for the temporary by copying that of the other side of the scalar assignment. PR fortran/29098 * resolve.c (resolve_structure_cons): Do not return FAILURE if component expression is NULL. 2006-11-06 Paul Thomas <pault@gcc.gnu.org> PR fortran/29373 * gfortran.dg/implicit_9.f90: New test. PR fortran/29407 * gfortran.dg/namelist_25.f90: New test. PR fortran/27701 * gfortran.dg/same_name_2.f90: New test. PR fortran/29232 * gfortran.dg/host_assoc_types_1.f90: New test. PR fortran/29364 * gfortran.dg/missing_derived_type_1.f90: New test. * gfortran.dg/implicit_actual.f90: Comment out USE GLOBAL. PR fortran/29115 * gfortran.dg/derived_constructor_comps_2.f90: New test. PR fortran/29211 * gfortran.dg/forall_char_dependencies_1.f90: New test. PR fortran/29098 * gfortran.dg/default_initialization_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/default_initialization_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/derived_constructor_comps_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/forall_char_dependencies_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/host_assoc_types_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_9.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/missing_derived_type_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_25.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/same_name_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/decl.c branches/gcc-4_1-branch/gcc/fortran/module.c branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/implicit_actual.f90