[Omp] Two simpler examples (Re: OpenMP spec 2.5 seems to have incorrect flush example on page 12)

[Greg Bronevetsky]

> Aargh! The compiler inserted memory references that changed the view
> of memory by one thread. That was legal because the compiler didn't
> know that another thread was viewing the memory. In essence the
> compiler added the race. So you have to tell the compiler that it
> can't do that. That is what flush is for. Or volatile.
> 
   Actually, that's a good way to summarize this optimization: the
compiler added a race. If the if(x)... code did execute, then the
compiler-generated race wouldn't matter since there would be an
application race to hide it. However, if if(x)... never executes, the
compiler-generated race just sits there exposed, visibly screwing things
up. The question that's not clear to me is whether possible races that end
up not actually happening at runtime should cause the result to be
undefined. If yes, then all is simple for implementors and the spec
(though worse for users). If not, we should be able to make a fairly
precise description of the kinds of optimizations that are not allowed.

   So which is it? I'm leaning toward no, simply because the yes
option will really confuse users.

                             Greg Bronevetsky