This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Signed int overflow behavior in the security context
- From: Joe Buck <Joe dot Buck at synopsys dot COM>
- To: Paul Schlie <schlie at comcast dot net>
- Cc: Robert Dewar <dewar at adacore dot com>, Andreas Bogk <andreas at andreas dot org>, gcc at gcc dot gnu dot org
- Date: Fri, 26 Jan 2007 16:11:51 -0800
- Subject: Re: Signed int overflow behavior in the security context
- References: <C1DFFFA7.FAE0%schlie@comcast.net>
On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote:
> > Robert Dewar wrote:
> >
> > People always say this, but they don't really realize what they are
> > saying. This would mean you could not put variables in registers, and
> > would essentially totally disable optimization.
>
> - can you provide an example of a single threaded program where the
> assignment of variable to a machine register validly changes its
> observable logical results?
If the program has a hash table that stores pointers to objects, and
the hash function depends on pointer addresses, then the choice to
allocate some objects in registers rather than in stack frames will change
the addresses. If the algorithm depends on the order of hash traversal,
then -O2 will change its behavior.
Likewise, if the program has an uninitialized variable, the behavior
will differ depending on details of optimization and how variables are
assigned to memory. Heap allocated for the first time might always be
zero (as the OS delivers it that way), turning on optimization might then
result in a nonzero initial value because of reuse of a register.
I'm sure others could give you many more examples.