Ian Lance Taylor wrote:
I fully appreciate that there is a real problem here which needs to be
addressed, but this does not seem like the best solution to me. A
great number of C programs are built using autoconf. If we make this
change, then they will all be built with -fwrapv. That will disable
useful loop optimizations, optimizations which are enabled by default
by gcc's competitors. The result will be to make gcc look worse than
it is.
The inclusion of -fwrapv is a good idea from the standpoint of producing
reliable code; it is a bad idea from the point of GCC PR.
Which begs the question: Should GCC care about its PR?
GCC suffers from many misconceptions due to its complexity. When it
comes to code optimization, GCC offers more options than any other
compiler I know. Literally hundreds of options combine in sometimes
surprising ways, allowing a knowledgeable GCC user to fine-tune their
code generation.
Back in the "old days", GCC was only used by expert UNIX hackers who
were educated about their tools. Today, GCC is being used by a more
general audience to develop consumer code. As such, GCC needs to err on
the side of reliability and backward compatibility, benchmarks be damned.
So if adding -fwrapv to autoconf keeps the current GCC from breaking
existing code at the cost of some speed, that's a Good Thing. Vendors
and Gentoo users who really care about performance can manually set
flags to boost their performance.
I don't want to see GCC "dumbed down" -- experts need a compiler with
this sort of fine-tuned power.
..Scott
