systematic miscompilation of volatile accesses

[John Regehr]

I just wanted to plug a study that a colleague and I recently
completed where we found that it is not uncommon for optimizing
compilers to generate incorrect code for accessing volatile objects.
This is, I think, no big surprise since volatiles are not that easy to
test and generating correct code entails getting a lot of special
cases right.

http://www.cs.utah.edu/~regehr/papers/emsoft08_submit.pdf

[Chris Thomasson]

"John Regehr" <reg...@cs.utah.edu> wrote in message
news:dfe0e4fd-e154-480c...@w4g2000prd.googlegroups.com...

Sounds like they are using a simple hack in the form of external function
calls. Well, link-time optimizations aside, this should work. Read the brief
introduction to this matter:

http://appcore.home.comcast.net

" The lock-free queue does not rely on any "atomic operations". It uses
simple loads and stores guarded with memory barriers. All of its
"critical-sequences" are contained in externally assembled functions:

http://groups.google.com/group/comp.programming.threads/msg/423df394a0370fa6

in order to prevent a rouge C compiler from reordering anything that would
corrupt the data-structure". Link-time optimizations can potentially break
this.