This is the mail archive of the
mailing list for the GCC project.
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
> I don't agree with this point. 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. We get a lot of bug reports about missed optimizations.
six vs. half a dozen. Picking one is an excellent idea.
Personally, -frisky makes a bit more sense because the performance
critical application writers tend to be more tuned in to tuning.
> Also, it does not make sense to me to lump together all potentially
> troublesome optimizations under a single name. They are not all the
No, but anything that makes things easier for application writers
is going to be useful. At some point, it may be useful to look
carefully at all the -Wmumble/-fgrumble options and provide
convenient ways to clump them without requiring surgery.
> 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.
Autoconf handles many, many C applications, even if there are very
few when compared to the universe of all C applications. :)
> I think I've already put another proposal on the table, but maybe I
> haven't described it properly:
> 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.
This is completely necessary without regard to any other decisions.
> 2) Add an option like -fstrict-signed-overflow which controls those
> cases which appear to be risky. Turn on that option at -O2.
Not a good plan. -O2 should be constrained to disrupting very few
applications. (e.g. loop unrolling seems unlikely to cause problems)
Defer the "appear to be risky" stuff to several years after the warning
is out. Please.
> It's important to realize that -Warnv will only issue a warning for an
> optimization which actually transforms the code. Every case where
> -Warnv will issue a warning is a case where -fwrapv will inhibit an
> optimization. Whether this will issue too many false positives is
> difficult to tell at this point. A false positive will take the form
> "this optimization is OK because I know that the values in question
> can not overflow".
Rethinking wrapping is going to take a lot of effort and will need
a lot of time.
Richard Kenner wrote:
> I'm not sure what you mean: there's the C standard.
We have many standards, starting with K&Rv1 through the current draft.
Which do you call, "the C standard"?