Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!think!ames!elroy!cit-vax!ucla-cs!zen!ucbvax!sfrod.UUCP!jmb From: jmb@sfrod.UUCP Newsgroups: comp.windows.x Subject: Re: Patch #68 Message-ID: <8712021832.AA22989@ucbvax.Berkeley.EDU> Date: Wed, 2-Dec-87 13:32:19 EST Article-I.D.: ucbvax.8712021832.AA22989 Posted: Wed Dec 2 13:32:19 1987 Date-Received: Sat, 5-Dec-87 17:35:25 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 32 In article <871123090636.6.RWS@KILLINGTON.LCS.MIT.EDU>, RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) writes: > > Date: 23 Nov 87 06:58:35 GMT > From: violet.berkeley.edu!jkh@jade.Berkeley.EDU (Jordan K. Hubbard) > > Patch #68 completely breaks the server when run on a Sun 3 monochrome. > I don't know if it breaks under the qvss/qdss/ibm > >It's working just fine for me on a Sun 3/110, an Apollo DN-3000, and a >DEC VS2000. But then, you probably guessed that already. Ah, yes, the infamous patch #68. Why on earth does it work fine for some folks while completely breaking the server for others? And why did it not work on our Sun-3/110C, one of the machines that RWS says it works fine on? After several dead-ends, I've finally found the answer: the Sun optimizer. I recompiled the file in question (dix/window.c) without -O on our Sun and everything now works fine. No doubt there is a quirk in the 3.2 optimizer that was fixed later releases, hence the discrepancy. Somebody with a bit of time on their hands might want to figure out exactly what it is in the patch that the optimizer doesn't agree with. Happy patching, Jim Bash | "Optimization is the AT&T Bell Labs | elimination of unused Room G-211, 190 River Road, Summit, NJ 07901 | generality." (201) 522-6649 | -- Steve Muchnick [...|ihnp4|bellcore|allegra]!attunix!jmb | via Peter Kessler