[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: Mark Mitchell
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Mon, 01 Jan 2007 11:46:41 -0800
User-agent: Thunderbird (Windows/20061207)

Ian Lance Taylor wrote:
> Paul Eggert <address@hidden> writes:
>>      * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an
>>      optional second argument specifying the default optimization
>>      options for GCC.  These optimizations now default to "-O2 -fwrapv"
>>      instead of to "-O2".  This partly attacks the problem reported by
>>      Ralf Wildenhues in
>>      <>
>>      and in <>.
> 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.

What a thread this has turned out to be.

I certainly don't think autoconf should make this change; as Ian and
others have said, we should find a way that -O2 is the right choice for
most programs.  That's important not just for programs using autoconf,
but for all programs using GCC.

So far, I've seen very little hard data in this thread, though I have to
admit I've had a hard time plowing through all the postings.

Here's what I have seen:

* Dan Berlin says that xlc assumes signed overflow never occurs, gets
much better performance as a result, and that nobody has complained.

* Others have said that much free software (including GCC, etc.) depends
on signed overflow wrapping.

I haven't yet seen that anyone has actually tried the obvious: run SPEC
with and without -fwrapv.  Would someone please do that?  Or, pick your
favorite high-performance application and do the same.  But, let's get
some concrete data as to how much this optimization helps.

Also, of the free software that's assuming signed overflow wraps, can we
 qualify how/where it's doing that?  Is it in explicit overflow tests?
In loop bounds?

Great performance is important; so is compiling dusty-deck code.
Striking a balance is hard.  We can't make this decision reasoning from
first principles.

Mark Mitchell
(650) 331-3385 x713

reply via email to

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