bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (08/27/88)
Environment: Sun 3/50, SunOS 3.5.1, GNU CC 1.26 + the m68k.md "match_operand" patch, X.V11R2 + 33 patches. CFLAGS = -O -traditional -fcombine-regs -fomit-frame-pointer for everything, including the server. When I compile xterm with gcc, everything is in the foreground color - that is, I get a solid black window. Compiled with the Sun cc, all is well. I see this effect with none of the other clients. What did I miss? -=- Zippy sez, --Bob Finally, Zippy drives his 1958 RAMBLER METROPOLITAN into the faculty dining room.
spaf@cs.purdue.edu (Gene Spafford) (08/27/88)
In article <20830@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: >When I compile xterm with gcc, everything is in the foreground color - >that is, I get a solid black window. Compiled with the Sun cc, all is >well. I see this effect with none of the other clients. > >What did I miss? You must have missed my postings on this in comp.windows.x: Subject: Speedups for X11.2 Xsun Summary: significant speedups, may work for other machines too [...some introductory text deleted] There are a few important things to do when compiling with gcc: [...some note about gcc 1.22 omitted] 3) You need to compile server/os/4.2bsd/oscolor.c with the Sun-cc compiler, or else you need to recompile and link the dbm library into the server (remember to remove the "-ldbm" from the Makefile in the server directory, too). The GNU compiler handles functions returning structures differently than pcc-based compilers, and "oscolor.c" uses the DBM "fetch" function to get items from a database. The distinctive symptom of forgetting to do this on monochrome is that your xterm windows may be all black or all white, depending on normal preference, and color monitors will be straight B/W. If you compile any of the clients, you may also need to use "-fwriteable-strings" to get around some sloppy coding, notably in xterm. Within few weeks we may post a complete set of diffs for compiling all the libraries and clients using all the gcc optimizations. Mostly these have required cleaning up some constant placement and code ordering. Compiling them with gcc doesn't make a major difference, in most cases, however. [...other notes on speedups omitted.] -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (09/03/88)
In article <4739@medusa.cs.purdue.edu> spaf@cs.purdue.edu (Gene Spafford) writes: |In article <20830@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: |>When I compile xterm with gcc, everything is in the foreground color - |>that is, I get a solid black window. Compiled with the Sun cc, all is |>well. I see this effect with none of the other clients. |> |>What did I miss? | |You must have missed my postings on this in comp.windows.x: | [...and the important information...] Thanks to Spaf and the others who pointed out that I simply had to compile server/os/4.2bsd/oscolor.c with Sun's cc, because of the difference between gcc's and pcc's struct-valued function return conventions. Someday soon I may make a GNU-compiled libdbm.a so this step won't be necessary. Except for oscolor.c, our Suns are running a completely gcc-compiled window system and client set now, with the Purdue speedups, and all is well. The performance improvement is remarkable! -=- Zippy sez, --Bob I smell a RANCID CORN DOG!
jkh@violet.berkeley.edu (Jordan K. Hubbard) (09/03/88)
In article <21283@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: >In article <4739@medusa.cs.purdue.edu> spaf@cs.purdue.edu (Gene Spafford) writes: >|In article <20830@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: >Thanks to Spaf and the others who pointed out that I simply had to >compile server/os/4.2bsd/oscolor.c with Sun's cc, because of the >difference between gcc's and pcc's struct-valued function return >conventions. Someday soon I may make a GNU-compiled libdbm.a so this >step won't be necessary. Maybe I was suffering from brain-lock, but when I tried this (linking in a GNU compiled libdbm.a), I got the same result. I ended up doing much the same thing (compiling oscolor.c with pcc), but was sort of curious as to why the GNU libdbm tossed its cookies. Anyone out there care to comment? Should I have used the gcc -fcompile-dbm-that-special-warm-feeling-kinda-way flag? Jordan
jeff1@garfield.mun.edu (Jeff Sparkes) (09/06/88)
In article <21283@tut.cis.ohio-state.edu>, bob@allosaur (Bob Sutterfield) writes: > >Thanks to Spaf and the others who pointed out that I simply had to >compile server/os/4.2bsd/oscolor.c with Sun's cc, because of the >difference between gcc's and pcc's struct-valued function return >conventions. Someday soon I may make a GNU-compiled libdbm.a so this >step won't be necessary. > Isn't this something that the -traditional flag should do? Jeff Sparkes jeff1@garfield.mun.edu