For the program module foo intger :: i ! intger should be integer end module foo program xfoo use foo, only: i end program xfoo gfortran -c -v gfbug.f90 gives Using built-in specs. Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran,c++,objc,obj-c++ --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --build=i386-pc-mingw32 --disable-shared --enable-libgomp Thread model: win32 gcc version 4.3.0 20070406 (experimental) c:/programs/gfortran/bin/../libexec/gcc/i386-pc-mingw32/4.3.0/f951.exe gfbug.f90 -quiet -dumpbase gfbug.f90 -mtune=i386 -auxbase gfbug -version -fintrinsic-modules-path c:/programs/gfortran/bin/../lib/gcc/i386-pc-mingw32/4.3.0/finclude -o C:\DOCUME~1\vrao\LOCALS~1\Temp/ccASnAoX.s GNU F95 version 4.3.0 20070406 (experimental) (i386-pc-mingw32) compiled by GNU C version 4.3.0 20070406 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 gfbug.f90:2: intger :: i ! intger should be integer 1 Error: Unclassifiable statement at (1) gfbug.f90:6.16: use foo, only: i 1 Fatal Error: Can't open module file 'foo.mod' for reading at (1): No such file or directory gfortran: Internal error: Aborted (program f951) Please submit a full bug report. See <URL:http://gcc.gnu.org/bugs.html> for instructions. Gfortran should "be quiet" after the "Fatal Error" message and not ask the user to submit a bug report.
With 4.3.0 20070404/x86_64-unknown-linux-gnu I don't get the ICE - and no problem is discovered using valgrind.
This bug was discussed in a Feb 2006 thread "suggestion regarding spurious(?) "internal error" message" http://gcc.gnu.org/ml/fortran/2006-02/msg00445.html . No one in that thread said they submitted it to bugzilla.
It appears that spurious ICE messages are a general problem with GCC. The site "Managing Bugs (Bugzilla and the testsuite)" at http://www.gnu.org/software/gcc/bugs/management.html says 'Bugs with keyword "ice-on-invalid-code", where GCC emits a sensible error message before issuing an ICE (the ICE will be replaced by the message "confused by earlier errors, bailing out" in release versions) should get "minor" severity and the additional keyword "error-recovery".'
(In reply to comment #3) > It appears that spurious ICE messages are a general problem with GCC. Well, it's true that an ICE on invalid code *and* after a sensible error message has been emitted does not have too large an impact for users. I can reproduce the ICE on minw32, but when I run f951 directly (instead of letting the driver calling it) it doesn't ICE (even with the same options as the driver passes to it). So, I can post a backtrace nor investigate :(
(In reply to comment #4) > (In reply to comment #3) > > It appears that spurious ICE messages are a general problem with GCC. > > Well, it's true that an ICE on invalid code *and* after a sensible error > message has been emitted does not have too large an impact for users. > > I can reproduce the ICE on minw32, but when I run f951 directly (instead of > letting the driver calling it) it doesn't ICE (even with the same options as > the driver passes to it). So, I can post a backtrace nor investigate :( I'm guessing that f951 exits with a non-zero exit status, and the driver catches that. >
Bugs where the compiler proper crashes when run under the driver, but not when run directly, can often be reproduced by varying the amount of space taken up by environment variables, e.g. x= while :; do x="x$x" X=$x ./f951 arguments... || break done
(In reply to comment #6) > Bugs where the compiler proper crashes when run under the driver, but not when > run directly, can often be reproduced by varying the amount of space taken up > by environment variables, e.g. Excellent advice, thanks very much! By making a variable x that contains 1064449 successive "1" characters, I get the following: $ X=$x c:/msys/1.0.10/home/fx/irun/mingw/libexec/gcc/i386-pc-mingw32/4.3.0/f951 .exe a.f90 -quiet Segmentation fault Unfortunately, I can't really debug it, because gdb itself segfaults when used with such a large environment variable. In fact, most programs I tried do segfault when used with this large environment variable (including as, ld, flex). So... now the question is more about how the driver ends up creating so large environment variables.
I used to see that, but now not any more. Does someone else still see this happening? And with what testcase?
Is this still a problem on ming32. Can we just drop support for ming32?
*** Bug 45575 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > I used to see that, but now not any more. Does someone else still see this > happening? And with what testcase? I can't reproduce this anymore for mingw-w64 based toolchain. So, I would suggest to close this bug.
Close as WORKSFORME. If it bites someone again, please reopen (or fill a new PR).
For what it is worth, that same code still causes an ICE with MinGW32 F:\brad\fortran\gfortran\tests>gfortran -c -v modbug1.f90 Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=d:/gfortran/bin/../libexec/gcc/i586-pc-mingw32/4.6.0/lto-wra pper.exe Target: i586-pc-mingw32 Configured with: ../gcc-trunk/configure --prefix=/mingw --enable-languages=c,for tran --with-gmp=/home/brad/gfortran/dependencies --disable-werror --enable-threa ds --disable-nls --build=i586-pc-mingw32 --enable-libgomp --disable-shared --dis able-win32-registry --with-dwarf2 --disable-sjlj-exceptions --enable-lto Thread model: win32 gcc version 4.6.0 20101201 (experimental) [trunk revision 167359] (GCC) COLLECT_GCC_OPTIONS='-c' '-v' '-mtune=pentium' '-march=pentium' d:/gfortran/bin/../libexec/gcc/i586-pc-mingw32/4.6.0/f951.exe modbug1.f90 -quie t -dumpbase modbug1.f90 -mtune=pentium -march=pentium -auxbase modbug1 -version -fintrinsic-modules-path d:/gfortran/bin/../lib/gcc/i586-pc-mingw32/4.6.0/finclu de -o C:\DOCUME~1\Brad\LOCALS~1\Temp\ccXYBQis.s GNU Fortran (GCC) version 4.6.0 20101201 (experimental) [trunk revision 167359] (i586-pc-mingw32) compiled by GNU C version 4.6.0 20101201 (experimental) [trunk revision 167359], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.6.0 20101201 (experimental) [trunk revision 167359] (i586-pc-mingw32) compiled by GNU C version 4.6.0 20101201 (experimental) [trunk revision 167359], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 modbug1.f90:2: intger :: i ! intger should be integer 1 Error: Unclassifiable statement at (1) modbug1.f90:6.16: use foo, only: i 1 Fatal Error: Can't open module file 'foo.mod' for reading at (1): No such file o r directory gfortran: internal compiler error: Aborted (program f951) Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. F:\brad\fortran\gfortran\tests> On 12/16/2010 1:37 PM, burnus at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519 > > Tobias Burnus<burnus at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|WAITING |RESOLVED > Resolution| |WORKSFORME > > --- Comment #12 from Tobias Burnus<burnus at gcc dot gnu.org> 2010-12-16 21:37:20 UTC --- > Close as WORKSFORME. If it bites someone again, please reopen (or fill a new > PR). >