Mail Archives: djgpp/2000/09/29/11:33:45
In article <8qa9to$hf8$1 AT antares DOT lu DOT erisoft DOT se>,
Martin Stromberg <eplmst AT lu DOT erisoft DOT se> 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
- Raw text -