[Bug fortran/31519] spurious ICE messages when module does not compile

[bafinney at myrealbox dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519

--- Comment #13 from bafinney at myrealbox dot com 2010-12-16 21:48:08 UTC ---
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  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  changed:
>
> What|Removed |Added
> 
>   Status|WAITING |RESOLVED
>   Resolution||WORKSFORME
>
> --- Comment #12 from Tobias Burnus  2010-12-16 
> 21:37:20 UTC ---
> Close as WORKSFORME. If it bites someone again, please reopen (or fill a new
> PR).
>

[Bug fortran/31519] spurious ICE messages when module does not compile

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519

Tobias Burnus  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||WORKSFORME

--- Comment #12 from Tobias Burnus  2010-12-16 
21:37:20 UTC ---
Close as WORKSFORME. If it bites someone again, please reopen (or fill a new
PR).

[Bug fortran/31519] spurious ICE messages when module does not compile

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519

Kai Tietz  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #11 from Kai Tietz  2010-12-16 21:27:48 
UTC ---
(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.

[Bug fortran/31519] spurious ICE messages when module does not compile

[fxcoudert at gcc dot gnu dot org]

--- Comment #10 from fxcoudert at gcc dot gnu dot org  2010-09-10 21:40 
---
*** Bug 45575 has been marked as a duplicate of this bug. ***


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||brad dot finney at humboldt
   ||dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519

[Bug fortran/31519] spurious ICE messages when module does not compile

[kargl at gcc dot gnu dot org]

--- Comment #9 from kargl at gcc dot gnu dot org  2010-01-17 23:06 ---
Is this still a problem on ming32.  Can we just drop support
for ming32?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519

[Bug fortran/31519] spurious ICE messages when module does not compile

[fxcoudert at gcc dot gnu dot org]

--- Comment #8 from fxcoudert at gcc dot gnu dot org  2009-05-13 19:37 
---
I used to see that, but now not any more. Does someone else still see this
happening? And with what testcase?


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu dot
   ||org
 Status|NEW |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519

[Bug fortran/31519] spurious ICE messages when module does not compile

[fxcoudert at gcc dot gnu dot org]

--- Comment #7 from fxcoudert at gcc dot gnu dot org  2007-07-13 15:47 
---
(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.


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2007-04-13 15:20:21 |2007-07-13 15:47:18
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519

[Bug fortran/31519] spurious ICE messages when module does not compile

[zackw at panix dot com]

--- Comment #6 from zackw at panix dot com  2007-04-15 21:22 ---
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519

[Bug fortran/31519] spurious ICE messages when module does not compile

[tobi at gcc dot gnu dot org]

--- Comment #5 from tobi at gcc dot gnu dot org  2007-04-15 20:08 ---
(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.
> 


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tobi at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519

[Bug fortran/31519] spurious ICE messages when module does not compile

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |minor
   GCC host triplet||i386-pc-mingw32
   Keywords||error-recovery, ice-on-
   ||invalid-code
   Last reconfirmed|2007-04-13 15:19:32 |2007-04-13 15:20:21
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519

[Bug fortran/31519] spurious ICE messages when module does not compile

[fxcoudert at gcc dot gnu dot org]

--- Comment #4 from fxcoudert at gcc dot gnu dot org  2007-04-13 15:19 
---
(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 :(


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-13 15:19:32
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519

[Bug fortran/31519] spurious ICE messages when module does not compile

[vivekrao4 at yahoo dot com]

--- Comment #3 from vivekrao4 at yahoo dot com  2007-04-10 23:51 ---
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".'


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519

[Bug fortran/31519] spurious ICE messages when module does not compile

[vivekrao4 at yahoo dot com]

--- Comment #2 from vivekrao4 at yahoo dot com  2007-04-10 19:38 ---
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519

[Bug fortran/31519] spurious ICE messages when module does not compile

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2007-04-10 07:12 ---
With 4.3.0 20070404/x86_64-unknown-linux-gnu I don't get the ICE - and no
problem is discovered using valgrind.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31519