From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <181b9e858518e43368953c1050365780@plan9.bell-labs.com> From: presotto@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] GUI toolkit for Plan 9 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-pujpubbhxmwbbygxaaljuullxb" Date: Tue, 26 Feb 2002 15:28:53 -0500 Topicbox-Message-UUID: 575c0e20-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-pujpubbhxmwbbygxaaljuullxb Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit You're right, there's plenty of blame to go around. More than once I was hoist on my own petard with C aliasing and saved by lots of 'volatile's. Not surprisingly I was screwed more than once by tail recursion optimizations on Sparc's (fun with register files) by lcc. Ditto with instruction ordering on MIPS. In all cases turning off optimization fixed the problem, regardless of where the fault lay. Hence, I can understand Rob's worry about optimization being an option rather than a requirement. Programmers tend to know that they are treading where lesser mortals fear to go when they up the optimization level. Especially with C, we are trained largely by what works and what doesn't. Moving from the VAX to the 68020 uncovered lots of null references that were going unnoticed in the past. Ditto for other coding outside the spec. If nothing slaps you down, you get complacent. Hence, we tend to accept the resulting errors and just back off optimization when it fails. We often don't report the bug because 1) not knowing the compiler writer, its often hard to say, ``When I use the -O256 flag, my 150,000 line program acts funny'' and expect to get any satisfaction. 2) we're afraid after 2 weeks of debugging it'll turn out to be our fault 3) once your code has been rewritten by a machine, its often incredibly hard to figure out what's broken 4) its not my job, man If things don't make it through with optimization turned off, then we report bugs because then we know its not our fault and have no recourse (except the first day trying to program around it). Hence, optimizing compilers tend to self select for retaining bugs. --upas-pujpubbhxmwbbygxaaljuullxb Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Tue Feb 26 14:48:24 EST 2002 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Tue Feb 26 14:48:23 EST 2002 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.30.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 844A919A80; Tue, 26 Feb 2002 14:48:09 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from ducky.net (ducky.net [199.26.172.91]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 28C2D19980 for <9fans@cse.psu.edu>; Tue, 26 Feb 2002 14:47:25 -0500 (EST) Received: (from mike@localhost) by ducky.net (8.11.6/8.11.4) id g1QJlJ043207 for 9fans@cse.psu.edu; Tue, 26 Feb 2002 11:47:19 -0800 (PST) (envelope-from mike) From: Mike Haertel Message-Id: <200202261947.g1QJlJ043207@ducky.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] GUI toolkit for Plan 9 In-Reply-To: Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Help: List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Tue, 26 Feb 2002 11:47:19 -0800 (PST) From 9fans-admin@cse.psu.edu Tue Feb 26 11:06:34 2002 From: presotto@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] GUI toolkit for Plan 9 Date: Tue, 26 Feb 2002 14:05:49 -0500 >However, it seems to be an >accepted consequence amongst compiler writers to trade off >possible incorrect code generation against probable speed >gains. I've been burned numerous times by upping the optimization >level in compilers including gcc. This is not a new development. >It was just as true 30 years ago with the fortran and PL1 compilers >I used. I'm not convinced that it's necessarily the compiler writers at fault in many of these cases. Certainly there are compiler and optimizer bugs, and probably the more optimization you apply the more likely you are to tickle these bugs. You can blame the compiler for those. But, at least in the case of C, there are numerous cases where people write code that is semantically undefined according to the detailed rules of the C standard, but does what they want under particular compilers or levels of optimization. (E.g. how many of you have assumed that local variables not declared volatile will hold their values across a longjmp?) So who to blame? The compiler writer, who assumes the code being compiled is standards-conforming? The standards committee, who get to decide which programming idioms will have defined behavior? The programmer, who often doesn't really understand the rules of the language? The authors of programming textbooks, who often downplay or omit these issues entirely? --upas-pujpubbhxmwbbygxaaljuullxb--