<div>These points are well-taken but I'd like to defend "naive compiler faith" a little bit. </div>
<div> </div>
<div>The a-priori job of the compiler, translating n-GL to (n-1) GL, can be reliably correct. A sufficiently expressive programming language will have to have some possible expressions which are not, but for most use the equivalent of eculidean geometry is just as reliable.  But there are (at least) two ways that actual compiler (implementations) disappoint us:
</div>
<div>1. Warnings. That used to be a separate job, as when C Beautify was an app we ran before CC. There is no limit to what we could like a computer to warn us about, that can't be in the scope of provable correctness. When "cc 
foo.c -o foo" returns "You don't have time for this, you're late for lunch!" it will be really cool :-)</div>
<div>2. Optimizations. A literal optimization does something like maximize the value of success in proportion to the cost of failure; so literally the optimal solution to a problem may have bugs, because the cost of sporadic bugs is smaller than the cost of avoiding them. An example would be the test "if fopen()..." which may just waste a microsecond every call, in the context that fopen() always succeeds unless the hard drive fails, when everything would fail and there would be no value catching it at that point in your app. A more theoretical example is probablistic primality; you can spend tiny time getting a number that is almost certainly prime, and use it in cryptography with very high (but not certain) safety. Or, you can spend years of CPU time proving the number is prime first. The optimal solution for most applications is to use the "buggy" probabilistic prime.
</div>
<div> </div>
<div>Surely some compiler suites provide cosier warnings (for your needs) and/or better optimizations, and more reliable optimizations, but it's just the strictly-compiling job that I (still) think of as highly reliable.
</div>
<div> </div>
<div>But the point is well-taken, I've been lucky to only need very few explicit registers deep in nested loops, so I've never had to worry much about how the compiler copes when availability is exceeded (although it's imaginable to me that wrapping around could be desired behaviour but that would have to be documented). You guys bang your machines pretty hard, I'm humbled.
</div>
<div> </div>
<div>Peter<br> </div>
<div><span class="gmail_quote">On 5/21/07, <b class="gmail_sendername">Toon Moene</b> <<a href="mailto:toon@moene.indiv.nluug.nl">toon@moene.indiv.nluug.nl</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Florent Calvayrac wrote:<br><br>> Without optimization no registers were used so the code was giving<br>
> correct results and at O1 code was optimized on a line per line basis<br>> and not procedure-wide.<br>><br>> So even commercial code can be wrong...<br><br>As a former boss of mine put it, some 25 years ago:  "You think the
<br>compiler is perfect ?   Hah, it's just another large program with its<br>own bugs !"<br><br>--<br>Toon Moene - e-mail: <a href="mailto:toon@moene.indiv.nluug.nl">toon@moene.indiv.nluug.nl</a> - phone: +31 346 214290
<br>Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands<br>At home: <a href="http://moene.indiv.nluug.nl/~toon/">http://moene.indiv.nluug.nl/~toon/</a><br>Who's working on GNU Fortran:<br><a href="http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html">
http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html</a><br></blockquote></div><br>