mike@thor.stolaf.edu (Mike Haertel) (12/08/88)
As everybody on this newsgroup knows, compiling gcc on the 3b1 is a bit of a chore, because it kind of exceeds several fixed limits of the SGS C compiler. Assuming you don't have a prior version of gcc to bootstrap from (and this may not be a good idea anyway) you will run into a few problems. First of all you will get "too much defining." You can fix this by replacing /lib/cpp with GNU cpp (save the old cpp somewhere!) When I last compiled gcc this way, I used cpp from the emacs 18.52 distribution (because cpp in the gcc distribution wants to include config.h . . .) There is a large bug in the emacs 18.52 cpp; there are a number of places where it does the comparison if (c == (UCHAR) -1) the cast to UCHAR needs to be removed; if I recall correctly. Then, assuming yohave a working cpp, you will get a weird error message from the C compiler further on; it is because of an enum type in one of the insn-*.h files with too many members for the poor SGS compiler to grok. You can change this file to a bunch of #defines and that ought to solve the problem. There may be further problems, but I don't know what they are because I never got a chance to finish compiling gcc this way; my disk started causing problems . . . (I don't *think* this was related to gcc :-) Incidentally, if it is just gnulib.c you want to compile (say, you're bootstrapping from a prior version of gcc and you want to compile the new gnulib with SGS cc) you can delete the line #include "config.h" and replace it with #define WORDS_BIG_ENDIAN because that is the only configuration parameter used in gnulib. I am presently running gcc-1.31. I did not bootstrap from a prior version of gcc (although in the distant past I once ran gcc-1.26). Instead, I cross compiled gcc from another machine (a sun 3, but I think you could probably do it from any machine). In order to do this, one builds an almost-3b1 gcc on the sun. I slightly modified the gcc configuration files to do this. % diff tm-3b1.h tm-3b1-from-sun.h 63c63 < #define SDB_DEBUGGING_INFO --- > /* #define SDB_DEBUGGING_INFO */ 68c68 < #define ASM_FILE_START(FILE) sdbout_filename ((FILE), main_input_filename) --- > #define ASM_FILE_START(FP) fprintf((FP), "\tfile\t\"%s\"\n", main_input_filename) % diff xm-3b1.h xm-3b1-from-sun.h 1,2d0 < #define USG < The main thing is you have to turn off SDB_DEBUGGING_INFO, and then you have to slightly fix ASM_FILE_START because you turned it off. The next thing is to copy the unix-pc include hierarchy over to the Sun. Now one reconfigures gcc with the default 3b1 configuration, and uses the almost-3b1 gcc just made to compile each c source file to an assembly language .s file, for example: % gcc -B./ -I3b1include -S -O toplev.c One then copies the .s files and gnulib.c to the 3b1, fixes gnulib.c so it compiles without config.h and builds gnulib, assembles the .s files, and load gcc, cc1, and cccp from the appropirate .o files with gnulib. (I used the shared library as well, and it worked.) I haven't gotten around to testing the thing much, but -O and -g both seem to work; I have successfully compiled the (as yet unreleased) GNU sort program that I wrote. I am going to copy the whole gcc distribution over; if gcc running on the 3b1 generates exactly the same .s files as gcc running on the Sun did (I have no reason to expect that it won't) then I will consider it to have passed that test. I will also use it to compile Emacs, TeX, and Metafont. With the latter two there are extensive test suites that I will run the results through; since TeX compiled with gcc-1.26 passed the trip test, I expect that TeX compiled with 1.31 will as well . . . Finally, no promises, but I may be able to make some 3b1 gcc binaries available via anonymous ftp from prep. -- Mike Haertel mike@wheaties.ai.mit.edu In Hell they run VMS.
brant@manta.pha.pa.us (Brant Cheikes) (12/09/88)
In article <796@thor.stolaf.edu> mike@wheaties.ai.mit.edu writes: >I haven't gotten around to testing the thing much, but -O and -g both >seem to work [...] >I will also use it to compile Emacs, TeX, and Metafont. The gcc-1.31 that I'm running successfully compiled the latest web2c/TeX/LaTeX available from ics.uci.edu. I needed the -traditional and -writable-strings options on web2c and tangle, but the actual web2c-generated C source compiled fine with just -O. The result passed the trip test, and was 10K smaller than the pcc-produced version. Speed-up of about 10-15% on compiling a 45-page document. I tried building Gnu Emacs 18.52 using every combination of -O, -traditional, and -writable-strings, with no luck. An executable was created that consistently core-dumped while loading rmail. I haven't tried to track the problem down. I will be putting the binaries in the anonymous Internet FTP area on linc.cis.upenn.edu within a few days. -- Brant Cheikes University of Pennsylvania Department of Computer and Information Science brant@manta.pha.pa.us, brant@linc.cis.upenn.edu, bpa!manta!brant
mike@thor.stolaf.edu (Mike Haertel) (12/11/88)
In article <455@manta.pha.pa.us> brant@manta.pha.pa.us (Brant Cheikes) writes: >The gcc-1.31 that I'm running successfully compiled the latest >web2c/TeX/LaTeX available from ics.uci.edu. I needed the -traditional >and -writable-strings options on web2c and tangle, but the actual >web2c-generated C source compiled fine with just -O. [. . .] > >I tried building Gnu Emacs 18.52 using every combination of -O, >-traditional, and -writable-strings, with no luck. An executable was >created that consistently core-dumped while loading rmail. I haven't >tried to track the problem down. I didn't need to use -fwritable-strings or -traditional to compile web2c. I got my copy from labrea.stanford.edu; the last time I looked that was more recent than the one available from ics.uci.edu. Emacs didn't work. After cross-compiling gcc, I downloaded the source and spent some time hunting around in the code. The following diff tells all. I used the bugged gcc to compile a clean one, and used that one to recompile itself, just in case. Emacs works now too. Or at least rmail and C-X C-B no longer dump core. I don't use rmail, but I *do* like the multiple buffer things; emacs as a single file editor just doesn't cut it :-) I am mailing these changes to Richard, so they should appear in the next version of gcc. *** tm-3b1.h~ Thu Nov 17 11:14:12 1988 --- tm-3b1.h Fri Dec 9 22:15:54 1988 *************** *** 282,287 if (scale != 1) fprintf (FILE, ":%d", scale); \ fprintf (FILE, ")"); \ break; } \ if (ireg != 0 || breg != 0) \ { int scale = 1; \ if (breg == 0) \ --- 282,293 ----- if (scale != 1) fprintf (FILE, ":%d", scale); \ fprintf (FILE, ")"); \ break; } \ + if (breg != 0 && ireg == 0 && GET_CODE (addr) == LABEL_REF) \ + { fprintf (FILE, "LD%%%d(%%pc,%s.l", \ + CODE_LABEL_NUMBER (XEXP (addr, 0)), \ + reg_name[REGNO (breg)]); \ + putc (')', FILE); \ + break; } \ if (ireg != 0 || breg != 0) \ { int scale = 1; \ if (breg == 0) \ -- Mike Haertel mike@wheaties.ai.mit.edu In Hell they run VMS.