[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: Wed, 20 Dec 2006 22:16:24 -0800
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Paolo Bonzini <address@hidden> writes:

> I have never, ever found a problem with the optimizations
> that GCC currently implements when -fwrapv is given;

Surely you meant to write "when -fwrapv is _not_ given"?

Anyway, this thread started because someone found a problem
with gcc -O2 (without -fwrapv).  And once he mentioned it, I
thought of dozens of similar time bombs ticking away in
software that I've looked at or helped to maintain.  Lots of
software assumes integer wraparound behavior.  The
assumptions are subtle and nobody has time to find them all,
much less rewrite the code.

If it's the GCC maintainers' position that these programs
are all broken unless you compile with -fwrapv, then -fwrapv
sounds like the best short-term fix for the problem.

Now -fwrapv in its current form is overkill, since it
disables many useful optimizations that won't break anything
(notably loop induction in the common case).  Perhaps we can
think of a stripped-down version that enables the most
useful optimizations without breaking C applications' tests
for overflow.  We could then enable that stripped-down
version by default, instead of -fwrapv.

> while -fwrapv severely pessimizes performance on several
> programs of mine.

In that case, we should make the Autoconf change optional.
I'll propose a further patch along those lines.

> The common idioms are actually not optimized by GCC, and some
> uncommon idioms have been optimized between 1992 and 2003 without
> any option to disable these optimization (and without anybody
> noticing?).

No, I noticed it in 1992 when such an optimization broke a
real program that I used, and complained about it then to
bug-gcc.  The optimization was disabled shortly after GCC
2.2.2 came out.  I considered the matter resolved.  See
a.k.a. <news:address@hidden> (1992-08-28) for a
brief summary.

However, <>
makes it appear that future versions of GCC are planned to
reintroduce some of these optimizations, which means gcc -O2
will start breaking more real programs again.  So I'd like
to do something about the issue again.

> and the compiler has every right to optimize,

GCC has _rights_?  (Somebody tell RMS!  :-)

gcc -O2 also could enable -ffast-math too.  That would
conform to the minimal C99 standard, and it would generate
faster code in some cases.  So why not do that as well?

The answer is obvious: many C applications assume not just
minimal C99, but also some properties of IEEE floating point
arithmetic (described in Annex F of C99).  If gcc -O2
enabled an optimization that broke IEEE, it'd break too many
of these programs.

The situation for -fwrapv is similar.  -fwrapv supports C99
+ LIA-1 wrapping arithmetic (described in Annex H of C99),
and many C programs assume this behavior.

Whether an installer should compile with -fwrapv is an
engineering decision -- should we risk breaking software
silently, or generate faster code? -- and different
maintainers will decide to default differently depending on
whether their software has been vetted carefully enough, and
on how important it is that their software works reliably
and portably.

We can't expect every maintainer to agree on these issues,
as their situations differ, so it's reasonable to provide an
Autoconf option, and I'll do that in a future version of the
patch.  However, prudence suggests that, if a maintainer
expresses no preference, the Autoconf default should prefer
safety to speed when we get into tricky areas like this.

> Move on, and read the language standard.

Let's move beyond the issue of what the C standard requires
at a minimum, and move on to the issue of what GCC +
Autoconf + etc. should support by default with commonly-used
options.  The two things are not the same, nor should they be.

reply via email to

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