This is the mail archive of the
mailing list for the GCC project.
Re: Autoconf manual's coverage of signed integer overflow & portability
- From: Paul Eggert <eggert at CS dot UCLA dot EDU>
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- 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, 03 Jan 2007 00:20:30 -0800
- Subject: Re: Autoconf manual's coverage of signed integer overflow & portability
- References: <200701030735.l037ZhV3019023@localhost.localdomain>
Andrew Pinski <firstname.lastname@example.org> writes:
> 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.
I wasn't there, but my impression is that many of the optimization
issues we've talked about in this thread were already well known by
the late 1980s, and the compiler writers were itching to share as much
backend stuff between C and Fortran as they could. I suspect users
were not consulted directly. I doubt whether saturation came into it;
that wasn't as popular back then.
But this is just my speculation.
> Also I think GCC still has a bug with respect of -fwrapv anyways on x86.
The problem with INT_MIN / -1 (and with INT_MIN % -1, too) is already
documented in the Autoconf manual, so it shouldn't need further
changes. In some sense INT_MIN % -1 is worse, since it's a standards
> Oh and fixing this bug will actually slow down users of -fwrapv
That's OK. That's what -fwrapv is for.
> there is no reliable way without using unsigned. Some targets
> in the future actually do saturation instead of wrapping
We can cross that bridge if and when we come to it.
> Old C programs that written against the C standard depend on signed
> overflow being defined as wrapping.
Much of the code in question is not that old, I'm afraid.
> I hope people learn from their mistakes in the past for depening on this
> behavior and actually instead of changing GCC, people fix up their code.
> I also hope programs written after 1989 don't depend on this behavior
I'm afraid your hopes will be dashed. It's been -- what? -- 18 years
since C89 came out, and it appears most C programmers haven't learned
yet. I see no reason to expect things to be different in the future,
if we just keep on doing what we have been doing.