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: Paul Schlie <schlie at comcast dot net>
- To: Robert Dewar <dewar at adacore dot com>
- 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: Mon, 20 Jun 2005 08:08:49 -0400
- Subject: Re: basic VRP min/max range overflow question
> From: Robert Dewar <dewar@adacore.com>
> Paul Schlie wrote:
>
>> I too believe I understand your position, however don't believe it's the
>> compiler's job to make life for the programmer harder than it need be when
>> a program may contain an undefined behavior; but agree it would likely
>> always be helpful to for it to point them out when identifiable.
>
> I really don't care too much about making life harder for the programmer
> who originally writes code if it makes it easier for people maintaining
> and porting the code down the line. I think it is a good idea if people
> writing C know C (substitute any other language you like for C here :-)
It's not clear to me that intentionally altering the semantics of a program
as a result of an undefined behavior in any single way is very productive
towards that goal, as unless the alternative behavior happens to be caught,
it may only likely result in a latent bug which the programmer thought
wouldn't occur based on the code specified, and/or the confirmed behavior of
the program prior to optimization. However having the compiler point out
potentially undefined non-portable expressions seems very useful, especially
if it attempts to maintain their semantics through optimization, albeit
non-portably.