This is the mail archive of the
mailing list for the GCC project.
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Ian Lance Taylor <email@example.com> writes:
> Also, it does not make sense to me to lump together all potentially
> troublesome optimizations under a single name.
As a compiler developer, you see the trees. But most users just see a
forest and want things to be simple. Even adding a single binary
switch (-fno-risky/-frisky) will be an extra level of complexity that
most users don't particularly want to know about. Requiring users to
worry about lots of little switches (at least -fwrapv/-fundefinedv/-ftrapv,
-fstrict-aliasiang/-fno-strict-aliasing, and probably more) makes GCC
harder to use conveniently, and will make things more likely to go
wrong in practical use.
That being said, I guess I wouldn't mind the extra complexity if
-fno-risky is the default at -O2. The default would be simple, which
is good enough.
> I don't really see how you move from the needs of "many, many C
> applications" to the autoconf patch. Many, many C applications do not
> use autoconf at all.
Sure, and from the GCC point of view it would be better to address
this problem at the GCC level, since we want to encourage GCC's use.
However, we will probably want to address this at the Autoconf level
too, in some form, since we also want to encourage GNU software to be
portable to other compilers with this problem, which include icc and
I think we will also want to address the problem at the Gnulib level
too, since we want it to be easier to write software that is portable
even to compilers or compiler options that have undefined behavior on
signed overflow -- this will help answer the question "What do I do
when -Warnv complains?".
> 1) Add an option like -Warnv to issue warnings about cases where gcc
> implements an optimization which relies on the fact that signed
> overflow is undefined.
> 2) Add an option like -fstrict-signed-overflow which controls those
> cases which appear to be risky. Turn on that option at -O2.
This sounds like a good approach overall, but the devil is in the
details. As you mentioned, (1) might have too many false positives.
More important, we don't yet have an easy way to characterize the
cases where (2) would apply. For (2), we need a simple, documented
rule that programmers can easily understand, so that they can easily
verify that C code is safe: for most applications this is more
important than squeezing out the last ounce of performance. Having
the rule merely be "does your version of GCC warn about it on your
platform?" doesn't really cut it.
So far, the only simple rule that has been proposed is -fwrapv, which
many have said is too conservative as it inhibits too many useful
optimizations for some numeric applications. I'm not yet convinced
that -fwrapv harms performance that much for most real-world
applications, but if we can come up with a less-conservative (but
still simple) rule, that would be fine. My worry, though, is that the
less-conservative rule will be too complicated.
> There is a substantial number of application developers who would
> prefer -failsafe. There is a substantial number who would prefer
> -frisky. We don't know which set is larger.
It's a controversial point, true. To help resolve this difference of
opinion, we could post a call for comments on info-gnu. The call
should be carefully worded, to avoid unduly biasing the results.