autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."


From: Ian Lance Taylor
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: 23 Mar 2007 18:31:22 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Paul Eggert <address@hidden> writes:

> >> GCC itself relies on wrapv semantics.  As does glibc.  And
> >> coreutils.  And GNU tar.  And Python.  I'm sure there are
> >> many other significant programs.  I don't have time to do a
> >> comprehensive survey right now.
> >
> > Where does GCC rely on that?  I don't see it anywhere?

> Thanks, but it's a lot of work to find bugs like this.
> Particularly if one is interested in finding them all, without a
> lot of false alarms.  I don't have time to wade through all of GCC
> with a fine-toothed comb right now, and I suspect nobody else does
> either.  Nor would I relish the prospect of keeping wrapv
> assumptions out of GCC as other developers make further
> contributions, as the wrapv assumption is so natural and
> pervasive.

I want to follow-up on this old thread.  For gcc 4.2 and later I have
implemented two new options.

The new option -fstrict-overflow tells gcc that it can assume the
strict signed overflow semantics prescribed by the language standard.
This option is enabled by default at -O2 and higher.  Using
-fno-strict-overflow will tell gcc that it can not assume that signed
overflow is undefined behaviour.  The general effect of using this
option will be that signed overflow will become implementation
defined.  This will disable a number of generally harmless
optimizations, but will not have the same effect as -fwrapv.

The new option -Wstrict-overflow will warn about cases where gcc
optimizes based on the fact that signed overflow is undefined.
Because this can produce many false positives--cases where gcc
uses undefined signed overflow to optimize that do not break any real
code--this option has five different levels.

-Wstrict-overflow=1
Warn about cases which are both questionable and easy to avoid.  For
example: x + 1 > x; with -fstrict-overflow, the compiler will simplify
this to 1.  This level of -Wstrict-overflow is enabled by -Wall;
higher levels are not, and must be explicitly requested.

-Wstrict-overflow=2
Also warn about other cases where a comparison is simplified to a
constant.  For example: abs (x) >= 0.  This can only be simplified
when -fstrict-overflow is in effect, because abs (INT_MIN) overflows
to INT_MIN, which is less than zero.  -Wstrict-overflow (with no
level) is the same as -Wstrict-overflow=2.

-Wstrict-overflow=3
Also warn about other cases where a comparison is simplified.  For
example: x + 1 > 1 will be simplified to x > 0.

-Wstrict-overflow=4
Also warn about other simplifications not covered by the above cases.
For example: (x * 10) / 5 will be simplified to x * 2.

-Wstrict-overflow=5
Also warn about cases where the compiler reduces the magnitude of a
constant involved in a comparison.  For example: x + 2 > y will be
simplified to x + 1 >= y.  This is reported only at the highest
warning level because this simplification applies to many comparisons,
so this warning level will give a very large number of false
positives.


For example, here is one of the test cases which started this
discussion:

extern int bigtime_test (int);
int
foo ()
{
  int j;
  for (j = 1; 0 < j; j *= 2)
    if (! bigtime_test (j))
      return 1;
  return 0;
}

This still becomes an infinite loop with -O2 (depending on what
bigtime_test does), but now issues a warning when using -O2
-Wstrict-overflow=2 (or simply -O2 -Wstrict-overflow):

foo.c:6: warning: assuming signed overflow does not occur when simplifying 
conditional to constant

With -O1 or with -O2 -fno-strict-overflow the loop terminates when j
overflows.

Ian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]