[cpp-threads] infinite loops

[Boehm, Hans]

> From: Lawrence Crowl 
> 
> On 8/16/06, Boehm, Hans <hans.boehm at hp.com> wrote:
> > Clearly the transformation is invalid if either count13 or 
> count17 is 
> > volatile or atomic, or if an opaque function call is involved.  But 
> > lots of compiler loop transformations that we do all the time have 
> > similar restrictions.  (If memory mapped I/O were involved, 
> one of the 
> > above better apply.)
> 
> So, the two statements
> 
>     f = 1.0; c = 1.0;
> 
> have different synchronization effects when
> 
>     float f; std::complex<float> c;
No, though the compiler may know less about the synchronization effects
of the latter.

I think we're misunderstanding each other.  They do have different
optimization effects if std::complex operations are treated as opaque by
the compiler.  But that's already the case, and we all knew that.  If
the compiler knows about std::complex, or performs transformations after
those operations are inline expanded, it should be able to perform the
same transformations in both cases.

Hans
> 
> What happens with direct compiler implementation of complex?
> Will the compiler be required to not optimize because the 
> standard cannot rely on a direct compiler implementation?  
> Will the programmer need to code around different compilers?
> 
> I think we are heading for trouble here.  I would rather we 
> have a specification that does not treat function calls 
> specially, because programmers do not know what calls are opaque.
> 
> --
> Lawrence Crowl
>