Re: [Valgrind-developers] valgrind: r6640 - trunk/memcheck

[Dirk M. <dm...@gm...>]

On Friday, 30. March 2007, Duncan Sands wrote:

> > it is a documented feature of gcc to not optimize away empty loops.
> Not anymore, this feature was removed in the gcc 4.x series.

Not entirely true: the documentation says: 

However, the rationale here is that optimization of a nonempty loop
cannot produce an empty one. This held for carefully written C compiled
with less powerful optimizers but is not always the case for carefully
written C++ or with more powerful optimizers.
Thus GCC will remove operations from loops whenever it can determine
those operations are not externally visible (apart from the time taken
to execute them, of course).  In case the loop can be proved to be finite,
GCC will also remove the loop itself.

In this case, there is a memory dereference involved (externally visible) and 
the compiler cannot prove that the loop is finite (since it doesn't know exit 
value of p). 

the next two levels of making sure the compiler doesn't optimize is 
volatile'ing p and calling an extern non-inline function with p after the 
loop. (which is a bit difficult because the vgpreload consists of only one 
compilation unit, I'd have to add a second one for that). 

Dirk