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