This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC optimizes integer overflow: bug or feature?
- From: Robert Dewar <dewar at adacore dot com>
- To: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- Cc: Andrew Pinski <pinskia at physics dot uc dot edu>, Paul Brook <paul at codesourcery dot com>, gcc at gcc dot gnu dot org, Denis Vlasenko <vda dot linux at googlemail dot com>, Andrew Haley <aph at redhat dot com>, Paolo Bonzini <bonzini at gnu dot org>, bug-gnulib at gnu dot org
- Date: Wed, 20 Dec 2006 06:56:07 -0500
- Subject: Re: GCC optimizes integer overflow: bug or feature?
- References: <200612200228.kBK2SGHp014855@localhost.localdomain> <20061220114610.GB16324@atrey.karlin.mff.cuni.cz>
Zdenek Dvorak wrote:
actually, you do not even need (invalid) multithreaded programs to
realize that register allocation may change behavior of a program.
If the size of the stack is bounded, register allocation may
cause or prevent program from running out of stack, thus turning a
crashing program to non-crashing one or vice versa.
Again, I think it is useful to distinguish functional behavior changes
from changes that come from resource utilization. Yes, optimization
will always change resource utilization. That's the whole point, so
if you include resource utilization as a change in behavior, then
you lose the useful distinction between optimizations like
a*2 => a+a
which could change the size of an executable
but which of itself is functionally neutral
from optimizations which are not functionally neutral for
programs with undefined or implementation defined semantics
(e.g. fast math).
Note that another possible effect of *any* optimization, is to
change the address of data and code throughout the program, and
of course this could wake up some implementation or buggy
behavior that depended on specific addresses of data or code.
Again, it is useful to exclude these indirect effects.