[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: Fri, 29 Dec 2006 13:29:27 -0800
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Ian Lance Taylor <address@hidden> writes:

> I fully appreciate that there is a real problem here which
> needs to be addressed, but this does not seem like the
> best solution to me.

I agree.  It's meant to be a stopgap.  I support coming up
with a better solution than the stopgap.

> The result will be to make gcc look worse than it is.

No, the proposed stopgap patch to Autoconf will make
actually GCC look _better_.

First, the patch will continue to give GCC an advantage over
random non-GCC compilers.  The default GCC compiler options
will be -g -O2 -fwrapv (assuming recent-enough GCC).  With
typical non-GCC compilers, the default options will be plain
-g.  That's a big advantage for GCC, albeit not quite as big
as -g -O2 would be.

Second, if you look at the fine print of the patch, you'll
find that it actually _disfavors_ icc, big-time.  Currently,
the default options for icc are -g -O2, because icc
currently mimics gcc well enough to pacify 'configure'.  But
with the proposed patch, icc will default to -g only.  This
is because icc does not support -fwrapv, and 'configure'
will discover this and disable all optimization with icc
(because that's the only way I know to get wrapv semantics
with icc).

> You will recall that the problem with the original code
> was not in the loop optimizers; it was in VRP.  I think we
> would be better served by changing VRP to not rely on
> undefined signed overflow.  Or, at least, to not rely on
> it without some additional option.

A change in behavior, or an additional option in that area,
would be a help, yes.  Another short-term possibility is for
configure to default to '-O2 -fno-tree-vrp' rather than to
'-O2 -fwrapv'.  I don't know whether that would be a win for
typical apps, though.  And it would be harder to explain,
which is why I chose -fwrapv.

The longer-term goal here is to come up with a way for
ordinary application programmers to easily find code that
has signed overflow problems, and replace it with simple,
portable code that can either avoid the overflow, or detect
it.  Part of the strategy might include "If you use GCC, be
careful not to use options such-and-such, because they're
not safe".  Or it might include calls to gcc-specific
builtins.  But whatever rules we use, they should be simple
and easy to apply.  Also, they shouldn't hurt performance
much, compared to the current (nonportable) code.

Currently we don't have anything even close to what would be
necessary here, and it'll be nontrivial to add it.  So the
shorter-term goal is merely to put up a temporary railing.

> Does anybody think that Paul's proposed patch to autoconf would be
> better than changing VRP?

I don't.

I haven't noticed anyone else addressing this question,
which I think is a good one.

reply via email to

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