Re: GCC optimizes integer overflow: bug or feature?

[Matthew Woehlke]

Dave Korn wrote:
> On 20 December 2006 02:28, Andrew Pinski wrote:
> > > Paul Brook wrote:
> > > > 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 timing matters now a
> > days.  Instruction scheduling can cause the same issue as it forces a write
> > too early for another thread to act on.
>
> Why isn't that just a buggy program with wilful disregard for the use of
> correct synchronisation techniques?

Excuse me while I beat you on the head with a number of real-life 
examples of *lock-free* algorithms. :-) Particularly lock-free queues 
(google should help you find one that applies here), whose correct 
operation is critically dependent on the order in which the loads and 
stores are performed. This is a very real, entirely legitimate example 
where the compiler thinking it knows how to do my job better than I do 
is wrong.

We (in a major, commercial application) ran into exactly this issue. 
'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this happens 
(it is a barrier across which neither the compiler nor CPU will reorder 
things). Failing that, no-op cross-library calls (that can't be inlined) 
seem to do the trick.

--
Matthew
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!