sverre@lars.Seri.GOV (Sverre Froyen) (01/01/91)
Dear All, For the past couple of days I have been trying to compile gcc on the pc532 under Minix. I am trying to compile gcc-1.38 using a set of patches from Finland (which installed without a hitch) and with Bruce's as and ld. The Minix is pretty much straight out of the box (Bruce's that is). The pc532 has 4MB memory installed. The first problem I ran into was that bison core dumped immediately. Undefining alloca and using the malloc version of alloca (from emacs or gcc) fixed that problem (but should not builtin_alloca work even under gcc-1.35???). Anyway I turned off builtin_alloca in my attempts to compile gcc. I have gotten as far as having everything link together and produce running copies of gcc, cc1, and cpp. These work fine on simple test programs. However when compiling gnulib2 or when trying to recompile gcc-1.38 I get fatal signal 6 (out of memory). Given 4MB of memory this somehow does not seem right. To test this further I wrote a small loop that allocates chunks of space. Depending on the chunksize I was able to malloc about 1.4MB before malloc returned 0. Can this be right and could this be the cause of my problems with gcc. Ideas anyone??? Sverre -- Sverre Froyen sverre@seri.gov, sunpeaks!seri!sverre
ian@sibyl.eleceng.ua.oz.au (01/06/91)
Sverre Froyen writes: > Dear All, > > The first problem I ran into was that bison core dumped immediately. > Undefining alloca and using the malloc version of alloca (from emacs > or gcc) fixed that problem (but should not builtin_alloca work even > under gcc-1.35???). Well, yes it should, but it doesn't. My version of gcc has a fix to make builtin_alloca work, but it adds an extra overhead on function returns. RMS says it will be fixed properly in gcc version 2. > programs. However when compiling gnulib2 or when trying to recompile > gcc-1.38 I get fatal signal 6 (out of memory). Given 4MB of memory > this somehow does not seem right. It could be. The optimisation can use a lot of memory (though I wouldn't have expected gnulib2 to be a problem). Try compiling the troublesome modules without -O. Ian Dall
news@daver.bungi.com (01/08/91)
>Ian Dall writes: >Sverre Froyen writes: ... > > ... However when compiling gnulib2 or when trying to recompile > > gcc-1.38 I get fatal signal 6 (out of memory). Given 4MB of memory > > this somehow does not seem right. >It could be. The optimisation can use a lot of memory (though I >wouldn't have expected gnulib2 to be a problem). Try compiling the >troublesome modules without -O. FYI: I had gcc run for about 24 hours using about 3 hours of CPU time optimizing one of the larger versions of flex. This happened under ISC i386 unix running on a Compaq with 8 Mbytes of memory. Here's part of ps from a partially complete run -- note the 141:18 minutes of cpu time on the last line of ps output. Compiling without "-O" is very likely the right idea. Efficiency loss should not be drastic. ====== ====== ====== ====== ====== ====== ====== ====== ====== halsoft:~/52> ps -fu jon UID PID PPID C STIME TTY TIME COMMAND ... jon 4807 4329 0 16:14:33 ttyp2 0:00 /bin/make bigtest jon 4879 4807 0 16:19:27 ttyp2 0:00 sh -ce rm -f scan.c ; make COMPRESSION="-Cf" test jon 4881 4879 0 16:19:28 ttyp2 0:00 make COMPRESSION=-Cf test jon 4884 4881 0 16:19:35 ttyp2 0:00 gcc -O -DUSG -traditional -c scan.c jon 4886 4884 0 16:19:40 ttyp2 141:18 /usr/local/lib/gcc-cc1 /usr/tmp/cca04884.cpp -quiet -dumpbase scan.c -O -tradit ... halsoft:~/53> date Sat Nov 17 15:43:27 PST 1990 ====== ====== ====== ====== ====== ====== ====== ====== ====== Good Luck: Jonathan Ryshpan <...!uunet!hitachi!jon>