Re: Autoconf manual's coverage of signed integer overflow & portability

[Andrew Pinski]

> 
> Here are further patches I checked into the Autoconf documentation to
> reflect today's comments (some of which I received privately).  Thanks
> to all of you.  The trickiest bit was documenting one simple way to
> reliably detect overflow without converting to unsigned and back.
> (At least, I hope it's reliable....)

Again there is no reliable way without using unsigned.  Some targets
in the future actually do saturation instead of wrapping so detecting
it in way you think is portable and reliable is actually not going
to detect it on those targets.  This is what I have been trying to
say for all my emails.

I would like to say the one thing I have not heard through this
discussion is the real reason why the C standards comittee decided
signed overflow as being undefined.  All I can think of is they were
thinking of target that do saturation for plus/minus but wrapping for
multiplications/divide or even targets that trap for some overflow cases
(like x86) but not others.

Also I think GCC still has a bug with respect of -fwrapv anyways on x86.
Take:

int f(int x, int y)
{
  return x/y;
}

int main(void)
{
  return f(0x80000000, -1);
}


This will always cause a trap on x86, even with -fwrapv so really
-fwrapv has a bug on x86.  I will file this bug sometime later
tomorrow.  Oh and fixing this bug will actually slow down users
of -fwrapv even more than what it is currently does because
you can no longer use the div instruction.  So even recommending
-fwrapv for those people who depend on signed overflow is wrong.


Thanks,
Andrew Pinski