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

[Paul Eggert]

"Daniel Berlin" <address@hidden> writes:

> Nobody has yet showed that any significant number of
> programs actually rely on this undefined behavior.

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.

> people who rely on signed overflow being wraparound generally
> *know* they are relying on it.

That is often true while they're writing the code, but
typically they wrote the code many years ago, and nobody now
remembers where all these assumptions are.

Also, even to this day there is no simple, portable way to
check for signed integer overflow of random system types,
unless you can assume wrapv semantics.  So people continue
to write new code that assumes wrapv semantics.

In practice, I expect that most C programmers probably
assume wrapv semantics, if only unconsciously.  The minimal
C Standard may not entitle them to that assumption, but they
assume it anyway.  Part of this is the Java influence no
doubt.  Sorry, but that is just the way the world goes.

> why don't [the people who need fwrapv] just compile
> *their* code with -fwrapv?

Because they typically don't know they might need fwrapv.
And even if they knew, there's no easy way to reliably
identify which subset of one's code is safe without -fwrapv.
And even if they knew where that subset was, there's
currently no convenient way to tell the Autotools about it.

The proposed Autoconf patch will address a part of this
problem, because it will raise general consciousness about
the issues with optimization and integer overflow.  And that
is a good thing, even if it's only a small part of the
problem.

> I posted numbers the last time this discussion came up,
> from both GCC and XLC, that showed that making signed
> overflow wraparound can cause up to a 50% performance
> regression in *real world* mathematical fortran and C
> codes

Obviously this is a compelling case, and if you know that
the code is safe without -fwrapv, it should be compiled
without -fwrapv.  The proposed patch will let you do that on
a package-by-package basis, as it gives a package's
maintainer a way to tell Autoconf to not assume -fwrapv by
default.  It would be better to have finer-grained control
on a module-by-module basis, but that will take more work
and in the mean time this should be good enough for most
important cases.

> I'll also point out that *none* of these codes that rely on signed
> overflow wrapping will work on any *other* compiler as well

No, they will work on other compilers, since 'configure'
won't use -O2 with those other compilers.

Unless you know of some real-world C compiler that breaks
wrapv semantics even compiling without optimization?  If so,
I'd like to hear the details.

> Most even optimize *unsigned* overflow to be undefined in loops at
> high opt levels (XLC does it at -O3+)

That shouldn't be a problem either.  'configure' has never
defaulted to such high optimization levels.