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: Robert Dewar <dewar at adacore dot com>
- To: Paul Schlie <schlie at comcast dot net>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Dale Johannesen <dalej at apple dot com>,Mike Stump <mrs at apple dot com>, Andrew Pinski <pinskia at physics dot uc dot edu>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Sun, 19 Jun 2005 22:44:12 -0400
- Subject: Re: basic VRP min/max range overflow question
- References: <BEDB3037.A8B5%schlie@comcast.net>
Paul Schlie wrote:
The root of the concern being expressed is with respect to the compilers use
of statically identified undefined behaviors as opportunities to invoke
alternative semantics which are easily identified as being inconsistent with
the target's native semantics, thus altering the logical behavior of the
program than would otherwise have resulted. (without any halting solutions
required)
You are still not understanding, these are NOT cases of "statically
identified undefined behavior". Those are the trivial cases that are
uninterestig.
As candidly, regardless of this being technically allowed, it should obvious
that any optimization which may likely alter the behavior of a program
should never be invoked without explicit request and ideally diagnosis of
the resulting alternative possibly undesired and/or fatal behavior.
If the behavior is undefined, then it is undefined, and you cannot
talk about a change in behavior. This is what non-deterministic semantics
is about.
To be more clear, specifically as examples:
- As VRP relies on the static analysis of value ranges, primarily based
on embedded implicit and/or explicit constant values which enables the
It most certainly is NOT possible to statically identify situations that
cause overflow. I cannot believe this is not clear to you.