moraes@CSRI.TORONTO.EDU (Mark Moraes) (04/21/89)
On Sun3s running SunOS3.5, we were able to compile the X11R3 server successfully with gcc-1.30, and gcc-1.31. It didn't work with gcc-1.32, and the original gcc-1.33 dumped core on several files in the server source. (This was fixed by a patch from RMS which earle@SUN.COM (Greg Earle) posted to gnu.gcc.bug) gcc-1.34 appears to compile the server happily without profiling; with -pg, it makes the Sun loader dump core, when linking a file in libcfb.a - haven't traced it any further yet. gcc-1.34 (and the patched 1.33) also compiles xbrowser properly - 1.30 dumped core on a source file in it. gcc-1.34 also generates correct code for xps (Crispin Goswell's PostScript interpreter) - when compiled with earlier versions, xps would dump core on startup. As a matter of interest, ordinary cc will still not compile it correctly with -O. xps passes structs with unions in them around on the stack - a very good way of testing compiler endurance, it seems. gcc-1.28 was successfully used to compile the X11R2 server on uVaxen. In all cases, we have seen substantial improvement in performance (20% or more) by using gcc (also 10-20% reduced binary size, depending what options you use - I prefer to use only -O, some may want to try -fstrength-reduce and -finline-functions); the PurduePlus or Purdue2.1 fixes take advantage of gcc inline assembler to improve performance further on Suns, at least. As the Purdue2.1 README notes, using gcc to compile Sun malloc, if you have source, also yields a considerable performance improvement. If you can find a faster malloc, you can try using if, provided it has a memalign() function. (the server uses this for allocating the space into which it maps the frame buffer) With gcc-1.34, we've also compiled most of the core applications and libraries, and those parts of contrib that had Imakefiles and manual pages with gcc (after getting around problems with sscanf() and mktemp() which I mentioned in an earlier note).
bert@opusc.CS.SCAROLINA.EDU (Bert Still) (05/11/89)
In article <89Apr20.202936edt.741@church.csri.toronto.edu>, moraes@CSRI.TORONTO.EDU (Mark Moraes) writes: > [Sun3's, with gcc-1.34, SunOS3.5, etc...] > In all cases, we have seen substantial improvement in performance (20% > or more) by using gcc (also 10-20% reduced binary size, depending what > options you use - I prefer to use only -O, some may want to try > -fstrength-reduce and -finline-functions); the PurduePlus or Purdue2.1 > fixes take advantage of gcc inline assembler to improve performance > further on Suns, at least. > Well, I have two differences: first, we have only SUN4's (and no SUN3's), and second, the binaries are about 3 times the size of the SUN cc generated ones... I used the following options: -O -traditional -fwritable-strings -finline-functions -fcombine-regs -Dinline=INLINE -DNOSTDHDRS -DPURDUE -DNO_3_60_CG4 -DTCPCONN -DUNIXCONN. I tried -fstrength-reduce, but I keep getting "cc1 caught fatal signal 4" presumably meaning an illigal instruction (perhaps a bad pointer?)... I also noticed that rgb dumps core (segmentation fault) when created with gcc-1.35. I've been poking around a bit with the rgb sources, but I can't see any reason for the core dump. If anyone has any suggestions on the "size" problem with X11R3, I'd sure like to hear it. X is a very nice windowing system, but I would like a litter faster execution speed... (I know, I keep saying gcc-1.35... but that's what the thing was named on osu-cis when I got it...) And now, I will go eagerly await the filling of my e-mailbox with wonderful ideas... :-) Bert bert%cs.scarolina.edu@RELAY.CS.NET ...!seismo!ncr-sd!ncrcae!usceast!bert -- Domain: bert%opus@cs.scarolina.edu ##### BITNET: T410119@UNIVSCVM LarynxNet: Bert Still AcadNet: Computer Services Division, University Of South Carolina