This is the mail archive of the
mailing list for the GCC project.
Re: gcc 3.5 integration branch proposal
>>>>> "Geoff" == Geoff Keating <email@example.com> writes:
Geoff> Paul Koning <firstname.lastname@example.org> writes:
>> >> * Correct code generation * Fewer ICEs * Standards conformance
>> * >> Compilation speed * Performance * Features * Release
>> frequency * >> Release timeliness
>> >> We need to figure out how to balance those goals better without
>> >> losing ground in areas where we recently have been improving.
>> I can see why some of this ordering would be subject to
>> disagreement, but I would hope that there also are partial
>> orderings that are NOT debatable.
>> The general rule of software engineering is that correctness comes
>> first, performance and schedule after that.
Geoff> I don't believe that statement is correct as an absolute.
Geoff> For instance, a product that never ships is *not* better than
Geoff> a product that ships with bugs. It is significantly worse.
Geoff> Likewise, a product that is guaranteed to produce the correct
Geoff> answer, but will take 400 years, is much worse than a product
Geoff> that has a 99% chance of producing the correct answer in 10
Depending on the mission, both of those statements are sometimes true
and sometimes completely false. Consider safety-critical applications
-- flight control, pacemaker firmware, things like that...
Other applications aren't quite as stringent, but still, a lot have
quality requirements well above those of typical PC applications.
Consider a storage server device -- if you're storing data for
thousands of users, you have to take correctness VERY seriously if you
want to stay in business. Shipping on schedule and then losing
customer data will not win you any friends at all.
Geoff> -- - Geoffrey Keating <email@example.com>