Paul Eggert wrote:
But so far, benchmark scores are the only scores given by the people
who oppose having -O2 imply -fwrapv.
And you expect real-world results will be different because...?
You say you doubt it affects performance. Based on what? Facts
please, not guesses and hand-waiving...
Eric Blake wrote:
/* The maximum and minimum values for the integer type T. These
macros have undefined behavior if T is signed and has padding bits.
If this is a problem for you, please let us know how to fix it for
your host. */
#define TYPE_MINIMUM(t) \
((t) (! TYPE_SIGNED (t) \
Paul Eggert wrote:
"Richard Guenther" <[EMAIL PROTECTED]> writes:
Authors of the affected programs should adjust their makefiles
That is what the proposed patch is for. It gives a way for
developers to adjust their makefiles.
A developer of portable software cannot simply put something
like
Paul Eggert wrote:
(2) In the current SPEC, how many programs benefit from undefined overflow
semantics and how much does each benefit?
Those questions are more for the opponents of -fwrapv, so
I'll let them answer them. But why are they relevant?
It's relevant in a "did my system just becom
Paul Eggert wrote:
That's great, but GCC has had many other hands stirring the pot.
I daresay a careful scan would come up with many other examples of
undefined behavior due to signed integer overflow. (No doubt
you'll be appalled by them as well, but there they are.)
That's handwaving, not ev
