>> > It's therefore not the responsibility of the programmer to check whether >> > the >> > result of optimization is correct. Therefore it's not the optimizations >> > that >> > are source of bugs, but bugs in GCC. >> >> But if you write a program and the user finds it full of bugs, are they >> going to care that you can say that it's GCC's fault? The burden falls > >When I write a program then I specify the language - say ISO/IEC 9899:1999. If >the compiler is buggy then it doesn't conform to ISO/IEC 9899:1999 - the >compiled program behaviour breaches the ISO/IEC 9899:1999 spec. Then it's the >user's problem that he compiled with a compiler that doesn't meet requirements >I clearly stated.
I remember back in university there were computing assignments where 50% of the marks were whether or not the program compiled or not. There were lots of student submissions that came in syntactically-correct, compiled but did not solve the actual problem that was the purpose of the assignment. 50% guaranteed rate of return on basically no effort? That's what the economics students might call an "optimization", especially so if you knew that the prof or TA wasn't going to look at the source. Make the program core out immediately after execution and they'd optimize their own time, give you the 50% and move on. So following in that line of thought, what about bugs that are procedural in nature but are otherwise syntactically-correct? Just because code compiles doesn't mean that it isn't wrong because of the methods used to come up with it... Since I answered my own rhetorical question, no one else needs to respond. Man, the signal-to-noise ratio of this list sure is bad lately....
