[Top][All Lists]

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

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

From: Paul Eggert
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Sat, 30 Dec 2006 14:19:56 -0800
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

address@hidden (Richard Kenner) writes:

> Date: Sat, 30 Dec 2006 08:01:37 EST
> I'd actually be very surprised if there were ANYPLACE where GCC has code
> that's otherwise correct but which would malfunction if signed overflow
> weren't required to wrap.

> Date: Sat, 30 Dec 2006 08:09:33 EST
>> Where does GCC assume wrapv semantics?
> The macro OVERFLOW_SUM_SIGN in fold-const.c.

So if I understand those two emails correctly, it took you
less than eight minutes to become very surprised....

I'm sure there are many other instances where the GCC source
code assumes wrapv semantics.  I was merely catching the
low-hanging fruit here, by searching for 'overflow' in the
source code.

The situation is worse for the other programs I mentioned,
because unlike GCC you didn't carefully vet their code for
this problem.  glibc, Emacs, coreutils, Python, etc., all
assume wrapv semantics.  Sometimes it's commented in the
code, sometimes not.  Nobody knows exactly how many places
in these programs assume wrapv, and nobody has the time to
find that out right now.  The assumption is pretty

> although it's hard to formally define the subset, it's
> hard to see how any of the optimizations proposed that
> take advantage of undefined overflow would, in practice,
> actually break this idiom.

That's good to know, but it's not enough to develop reliable
software.  If we go this route we need to define a useful
safe subset: one that's reliable, is easy for programmers to
understand, and where violations of the policy elicit useful
diagnostics.  We're nowhere close to this right now, so some
real work needs to be done.

Let me try to document the current situation with GCC:

  If you compile with -O2 but without -fwrapv, signed
  integer arithmetic has undefined behavior on overflow.
  Overflow might wrap, or crash, or loop, or silently give
  the wrong answer, or cause unexpected behavior even before
  the overflow occurs.

  Notwithstanding the above, if you assume wrapping
  semantics for the purpose of checking for signed overflow,
  and if you don't do the checking for a loop index, or in a
  way that might be interpreted by the compiler as being
  related to a loop index after optimizations that we don't
  have time to document precisely and which change from
  version to version, then you should be OK with gcc -O2
  even if you don't use -fwrapv.

  However, notwithstanding the above, if a future version of
  GCC comes out that optimizes better, and if your
  application's overflow-checking code stops working, then
  that's your problem.  gcc -O2 makes no promises without

Anybody who's developing reliable software will read the
second two paragraphs and wonder why I even bothered to
write them down.  The first paragraph is all that counts.

We need to do better than this.

reply via email to

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