From: clc5q AT cobra DOT cs DOT Virginia DOT EDU (Clark L. Coleman) Newsgroups: comp.os.msdos.djgpp Subject: Program too big to compile (was Re: missing cc1plus.exe file) Date: 29 Sep 2000 14:40:27 GMT Organization: University of Virginia Lines: 54 Message-ID: <8r29kr$opd$1@murdoch.acc.Virginia.EDU> References: <_spx5.40284$XZ4 DOT 513027 AT news DOT infostrada DOT it> <8q9vhv$dlq$1 AT antares DOT lu DOT erisoft DOT se> <8qa77h$q71$1 AT murdoch DOT acc DOT Virginia DOT EDU> <8qa9to$hf8$1 AT antares DOT lu DOT erisoft DOT se> NNTP-Posting-Host: cobra.cs.virginia.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com In article <8qa9to$hf8$1 AT antares DOT lu DOT erisoft DOT se>, Martin Stromberg wrote: >Clark L. Coleman (clc5q AT cobra DOT cs DOT Virginia DOT EDU) wrote: >: It turns out that cc1 is getting "divide overflow" errors and >: terminating. The FOO.O file is an old one, not being recreated each >: time. So, this is another "too big for gcc to handle" problem, I >: think, as the file being compiled has really big basic blocks, big >: switch statements,long distance branches, etc. Compiles fine in >: Solaris, IRIX, etc. environments with gcc 2.8.1 and 2.95.x, but not >: with latest 2.95.2 in DJGPP. What next? > >Any error messages? Stack dumps? (Complete, to be useful.) > >Perhaps cc1 needs a bigger stack. Try reading FAQ 15.9. How much >memory do you have (go32-v2)? > By increasing the minstack of cc1.exe and as.exe using stubedit, I can get the error messages to change. As I progress the cc1.exe minstack up towards 24 MB, the "divide overflow error" problems become "virtual memory exhausted" problems, and then finally become "I/O error" messages as cc1.exe tries to write to its temporary *.s file (which is some temporary mangled-looking filename prefix.) It never makes it to the as.exe stage of the compilation. The system has 128 MB of RAM, running NT 4.0 with Service Pack 6, and go32-v2 shows about 70 MB available. The file I am compiling is an experimental file that is very large because it is being used as a dummy to produce ITLB and I-cache misses for some research experiments. Otherwise, it performs no useful computation. The object code file, if it could be produced successfully, would be about 1.2 MB (and it is produced successfully, by both gcc 2.8.1 and gcc 2.95.2, on Unix systems.) As I increase the minstack of cc1.exe from 24 MB up to 64 MB, nothing changes. I still get "I/O error" on the assembly language output file. As I have a multi-boot system, I am thinking of trying to compile a version under Linux at full size, and reduce the size of the DJGPP version. I can compile successfully, under DOS or NT, if I #ifdef out about 35% of the source code, producing about 700KB of object instead of 1.2 MB. And the minstack of 24MB is more than sufficient for this, while making the code size 50% bigger and upping the minstack to 64 MB is insufficient. I suspect that the "I/O error" is based on the size of the output assembly file, and is independent of the minstack parameter. If anybody really wants to look into it, I can provide web access to a source file and headers that will exhibit the problem. Thanks for everyone's input. Clark Coleman