This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: basic VRP min/max range overflow question
- From: Michael Veksler <VEKSLER at il dot ibm dot com>
- To: Paul Schlie <schlie at comcast dot net>
- Cc: Dale Johannesen <dalej at apple dot com>, Robert Dewar <dewar at adacore dot com>, GCC Development <gcc at gcc dot gnu dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, Mike Stump <mrs at apple dot com>, Andrew Pinski <pinskia at physics dot uc dot edu>
- Date: Mon, 20 Jun 2005 15:53:07 +0300
- Subject: Re: basic VRP min/max range overflow question
Paul Schlie wrote on 20/06/2005 14:13:33:
> > From: Robert Dewar <dewar@adacore.com>
...
> > Note that in the cases where something is statically optimized away
(these
> > are the easy cases), it is nice if the compiler warns that this is
happening
> > (that would certainly be the case in Ada in the corresponding
situation, not
> > sure about C++). But of course no such warning is required.
>
> Agreed. And given that the standard enables an implementation to do
anything
> upon encountering an undefined behavior, it just seems just as correct to
> simply presume that the behavior will be consistent with the targets
native
> behavior; as just because it may enable the compiler to do anything, it
> doesn't imply that it should, or that it would be a good idea to do so.
>
Agreed in theory. Can you define "to do anything" ? What aspects
of the language can be defined as "native behavior"? What aspects
are always undefined? (e.g. uninitialized pointer dereference?).
As for overflow, you can say that you want instead of "undefined"
to treat is "unspecified". Where each architecture / opsys / compiler
must consistently define what happens on overflow:
- saturation
- wrap 2's (or 1's) complement
- exception.
You can argue (and maybe show benchmarks) that the above
"unspecified" does not inhibit too many real world optimizations,
as compared with "undefined". If that were the case, you would
have a chance convincing the std and gcc of your views.
However, generalizing things for all "undefined behavior" is
doomed to failure. Not all "undefined behaviors" were born equal,
and you can't treat them as equal, unless they
"enable the compiler to do anything".
You can be pragmatic, and try hard to minimize the cases where
the compiler happens "to do anything", but you cannot formally
guarantee that it will never happen. If you are not careful you may
end up with a spaghetti compiler full of special code geared
at the avoiding many of the "to do anything" cases.
Michael