autoconf-patches
[Top][All Lists]
Advanced

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

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


From: Richard Kenner
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Sat, 30 Dec 2006 17:30:30 EST

> Here's an example from the intprops module of gnulib.  

These are interesting case.

Note that all the computations are constant-folded.

And I think this points the fact that we can "have our cake and eat it too"
in many cases.  Everything we're seeing points to the fact that the cases
where assuming undefined behavior for overflow will help optimizations are
cases where few if any sane programmers would write the code depending on
wrap semantics (e.g., loop variables).  And nearly all the cases where wrap
semantics are expected (e.g., the above) are such that there's no reasonable
optimization benefit in assuming they're undefined.

Take constant folding: if we were pendantic about it, we could say, "this
folded expression overflows and so is undefined, so let's set its value to be
whatever constant would yield the most efficient code in that case".

Such behavior would be standard-compliant, but as unfriendly as possible
because it wouldn't "optimize" any real code, just break common idioms.
I doubt anybody would suggest not implementing wrapping semantics in
constant folding.

> I would really like to see gcc be able to warn when it is exploiting
> optimization opportunities based on undefined wrap semantics, so that code
> can easily be made robust against overflow without having to rely on
> tedious code audits.  In my opinion, the expectation of sane overflow
> semantics is just too pervasive in existing code to be able to audit
> without compiler assistance.

Even if you avoid doing things like the above?   The problem is that
such opportunities are all OVER the place and, in practice, there are nearly
no actual overflows, so the number of false positives of such a warning
is HUGE.




reply via email to

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