--- In liblf-dev@yahoogroups.com, Bjorn Roche <bjorn@...> wrote:
>
> Many optimizing compilers will make things work, not because they
> should work, but because optimizers like to remove operations and that
> tends to make things more atomic. Plus, gcc, for example, tends to
> insert memory barriers in places, like at function calls. In many
> cases, things can work because datastructures happen to be stable
> enough, even in light of weak ordering. However, all this is difficult
> to predict -- especially if you want your app to be portable across
> compilers and CPUs.
>
> Occasionally, I've seen people comment that you have to let these
> things run a really long time in order to see failure, but that's not
> usually the case. Usually, if a test fails to fail (!) it's probably
> because your compiler has done something, or you just haven't found a
> case where it fails. Since absence of proof is not proof of absence,
> and there were a lot of doubters out there, I wrote a counterexample
> that failed on a standard PPC mac. You can find it if you search the
> archives. I'm not sure anyone ever scrutinized it (even me -- I wrote
> it super fast), so it may have done what it did due to a bug, but if
> you doubt weak ordering I assure you very smart people have spent a
> long time building it into the next revision of c++ and I don't think
> they would have done that if it weren't necessary. But you can look at
> my code if you doubt it, and if it happens to run on your machine,
> you'll have to tweak it or take my word for it, as I no longer have
> the machine that code used to run on.

Thanks for your answer. Is this the counter example you mention:
http://tech.groups.yahoo.com/group/liblf-dev/message/203 ?

--
Olivier Guilyardi / Samalyse