This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
gfortran 4.1.0-cvs cygwin build failure: ICE on environ.c (!)
- From: Brooks Moses <bmoses-nospam at cits1 dot stanford dot edu>
- To: fortran at gcc dot gnu dot org
- Date: Sat, 04 Jun 2005 02:10:44 -0700
- Subject: gfortran 4.1.0-cvs cygwin build failure: ICE on environ.c (!)
- Organization: Stanford University, Mechanical Engineering
After Paul T.'s post on Wednesday accused Cygwin users of being lazy
bums (well, not really), I figured I should get off my duff and actually
install gfortran on my Cygwin machine and see how it ran. Short answer:
it doesn't, and I'd like some advice on what next, and whether this
merits a Bugzilla report and what I should put in the report (as I
haven't done this sort of thing before).
Ok, so. Step 1: I fire up cvs, and check out the source as per the
instructions on the Wiki. All goes well. The system that I'm using is
my venerable home work machine, a 200MHz Pentium Pro running Win2k and
Cygwin, with all the Cygwin stuff updated about two or three months
ago. Since the website (I don't remember where) mentioned depending on
bison, I installed that from Cygwin before starting.
Step 2: Set up environment variables and run configure, as per a recent
post in comp.lang.fortran (with the options taken from the post):
setenv CFLAGS '-O2 -g'
setenv BOOT_CFLAGS '-O2'
cd gcc/gcc
../configure --enable-threads=posix
--enable-sjlj-exceptions --disable-libmudflap
--enable-languages=f95
This, again, works fine. (Well, I think it gave me an error about a
missing library the first time, so I installed that via Cygwin setup,
and then it ran fine.)
Step 3: run "make bootstrap-lean".
This failed, an hour or so in, due to my not having flex installed.
Since the error message mentioned that I shouldn't need flex installed
unless I modified a .l file, I found this a bit odd, but I went and
installed flex.
(Should I report that as a bug? I saved the build output from around
when it was doing that.)
So, I installed flex, and ran "make bootstrap-lean" again, and let
things churn.
Twenty-six hours later, after getting through the compilations in the
"stage 1" and "stage 2" directories, it crashed with the following
output:
> /cygdrive/e/gfortran/gcc/gcc/./gcc/xgcc -B/cygdrive/e/gfortran/gcc/gcc/./gcc/ -B/usr/local/i686-pc-c
> ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr
> /local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I. -I../../../libgfortran -I. -iquote../../../lib
> gfortran/io -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra
> -Wwrite-strings -O2 -g -O2 -c ../../../libgfortran/runtime/environ.c -o environ.o
> ../../../libgfortran/runtime/environ.c: In function 'init_integer':
> ../../../libgfortran/runtime/environ.c:104: error: invariant not recomputed when ADDR_EXPR changed
> &_ctype_D.1970[1];
>
> ../../../libgfortran/runtime/environ.c:104: internal compiler error: verify_stmts failed.
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> make[3]: *** [environ.lo] Error 1
> make[3]: Leaving directory `/cygdrive/e/gfortran/gcc/gcc/i686-pc-cygwin/libgfortran'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/cygdrive/e/gfortran/gcc/gcc/i686-pc-cygwin/libgfortran'
> make[1]: *** [all-target-libgfortran] Error 2
> make[1]: Leaving directory `/cygdrive/e/gfortran/gcc/gcc'
> make: *** [bootstrap-lean] Error 2
So, I saved a copy of environ.c (which looks perfectly innocuous) for
future reference, and restarted "make bootstrap-lean" to see if it
failed again.
Unfortunately, it appears that the "make" process is now rather deeply
wedged. The first run-through had apparently just finished the "stage
2" build and cleared everything out of those directories before it
crashed. However, when I restart the process, it tries to run tail on
all of the object files in the stage2 directories, which are now empty,
and so it fails.
Thus, my questions: ought I to file the bug report about the build
failure? If so, what do I need to include in it to properly illustrate
the problem? And what can I do to unwedge my build process (preferably
without having to redo the whole 26 hours of compilation!) once that's
dealt with?
Thanks!
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.