This is the mail archive of the
mailing list for the GCC project.
Re: Autoconf manual's coverage of signed integer overflow & portability
- From: Andrew Pinski <pinskia at physics dot uc dot edu>
- To: eggert at CS dot UCLA dot EDU (Paul Eggert)
- Cc: autoconf-patches at gnu dot org, autoconf at gnu dot org, bug-autoconf at gnu dot org, bug-gnulib at gnu dot org, gcc at gcc dot gnu dot org
- Date: Wed, 3 Jan 2007 02:35:43 -0500 (EST)
- Subject: Re: Autoconf manual's coverage of signed integer overflow & portability
> 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.
int f(int x, int y)
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.