herndon@milo.SRC.Honeywell.COM (William Herndon) (06/06/89)
First, of all thanks to all those who sent me patches that would allow gcc to compile on my 3b1. Now, on to the current problem. I have managed to get gcc, version 1.35, to compile using cc. The executable of the parser is about 6.6M and appears to run correctly. After completing the initial make, I tried to recompile gcc with itself, as the installation guide suggested. The compile proceeds smoothly until the cc1 starts work on c-parse.tab.c. After thinking about it for a few minutes unix complains about virtual memory being exhausted, and the make aborts. Below is all the relevant information I can think of: - My system is a 3b1 with 2M of onboard memory. ( 40M drive ). - I do not have Bison running so a new c-parse.tab.c has not been created. - The compilation always aborts in the same place. - I have attempted to create more space ( swap I assume ) by running as root with no window manager. I have even gone so far as to kill off the phone manager and lp scheduler to free up more space. - The initial compilation with cc was using -O. So gcc, cc1, and cpp are optimized. - I have the same problem attempting to compile GNU Emacs file regexp.c. Any body have ideas? Encountered the same problem? Any and all help is appreciated. --------------------------------------------------------------------------- William R. Herndon WHerndon@cim-vax.honeywell.com herndon@src.honeywell.com SCTC, Honeywell 2855 Anthony Ln. So. #130 (612) 782-7108 St. Anthony, Mn. 55418 The opinions expressed are solely those of the author. Any resemblance to other opinions, either living or dead, is purely coincidental.
alex@wolf.umbc.edu (Alex Crain) (06/07/89)
In article <23146@srcsip.UUCP>, herndon@milo.SRC.Honeywell.COM (William Herndon) writes: > suggested. The compile proceeds smoothly until the cc1 starts work > on c-parse.tab.c. After thinking about it for a few minutes unix > complains about virtual memory being exhausted, and the make aborts. Try compiling without -O (this works with 1.31) This is becoming a serious problem (the size of gcc). Virtual memory exausted means that you have run out of virtual address space, a problem wothout a solution. The worst case that I've seen is in gas. the file m68k.c in gas kills gcc with virtual memory exausted, and also causes cc to produce bogus assembly code! The solution that time was to split the file into two smaller files and link the objects together (yuuch!) but that won't work with large bison output because bison output is generally one function (double yuck!) that can't be split. It would be nice if gcc got more effecient, but since the usually culprit is bison/yacc files, one option is to do an end run around the problem and build a bison that would buoid a jump table of absolute branches, and then compile the individual cases separately as static functions using common global variables. Kinda gross, but it'll hold us over until somebody profiles the memory allocation in gcc. ################################# :alex. #Disclamer: Anyone who agrees # University of Maryland Baltimore County #with me deserves what they get.# alex@umbc3.umbc.edu ################################# alex%nerwin@umbc3.umbc.edu
kevin@kosman.UUCP (Kevin O'Gorman) (06/07/89)
In article <23146@srcsip.UUCP> herndon@milo.SRC.Honeywell.COM (William Herndon) writes: > Now, on to the current problem. I have managed to get gcc, version > 1.35, to compile using cc. The executable of the parser is about > 6.6M and appears to run correctly. After completing the initial > make, I tried to recompile gcc with itself, as the installation guide > suggested. The compile proceeds smoothly until the cc1 starts work > on c-parse.tab.c. After thinking about it for a few minutes unix > complains about virtual memory being exhausted, and the make aborts. > Any body have ideas? Encountered the same problem? Any and all > help is appreciated. No particular ideas, at least about why this happens to you. Well, one idea: cc may be so busted that the resulting gcc is also busted. I have gcc 1.35 running on my 3b1 (with 2.5 MB main memory, and a swap space of 5000 blocks). It was compiled by bootstrapping from a previous version, without any reported memory trouble. I run with UA, as a normal user, all the time. The port from cc to gcc was done many versions ago by someone else. You might want to run iv -tv /dev/rfp000 # type this exactly. Do not goof. to see the size of your swap space (the second partition, "Part 1").