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: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- Cc: Robert Dewar <dewar at adacore dot com>, 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 12:46:10 +0100
- Subject: Re: GCC optimizes integer overflow: bug or feature?
- References: <200612200228.kBK2SGHp014855@localhost.localdomain>
Hello,
> > Paul Brook wrote:
> > >> Compiler can optimize it any way it wants,
> > >> as long as result is the same as unoptimized one.
> > >
> > > We have an option for that. It's called -O0.
> > >
> > > Pretty much all optimization will change the behavior of your program.
> >
> > Now that's a bit TOO strong a statement, critical optimizations like
> > register allocation and instruction scheduling will generally not change
> > the behavior of the program (though the basic decision to put something
> > in a register will, and *surely* no one suggests avoiding this critical
> > optimization).
>
> Actually they will with multi threaded program, since you can have a case
> where it works and now it is broken because one thread has speed up so much it
> writes to a variable which had a copy on another thread's stack. So the argument
> about it being too strong is wrong because timming matters now a days. Instruction
> scheduling can cause the same issue as it forces a write too early for another thread
> to act on.
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.
Zdenek