[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [csmith-dev] mission drift proposal #2 -- C++0x memory model



Chucky

I don't know anything about C++, so I don't know how similar the constructs
are, but it would be great if what you generated could be used for C as
well.  C1X has atomics with different kinds of memory ordering constraints,
and of course threads with locks and mutexes.

WG14 and WG21 worked closely together to make sure that the
common subset was compatible.

There were some last minute tweaks at he WG14 meeting in London a
couple of months ago.
http://shape-of-code.coding-guidelines.com/2011/03/17/a-change-of-guard-in-the-c-standards-world/


-Chucky

On Thu, Jun 9, 2011 at 3:34 PM, John Regehr<regehr@cs.utah.edu>  wrote:

It looks like some compilers (for example GCC) are not too far from being
ready to try to comply with the C++0x memory model.  This will be a big job
and they do not yet fully understand how this model will interact with their
optimizer.  It's fair to say that most other C++ compilers will be running
into similar issues in coming years.  We can help by adding C++0x memory
model constructs to the set of things Csmith can emit.

Note that I'm not suggesting that we emit "interesting" C++, which is a
very big job.  Rather, we can emit C++ that looks very much like C but that
contains locks, atomics, volatiles, etc.  I can't imagine there's anything
difficult about this, given the infrastructure we already have.

Hans Boehm has an excellent slide deck on what can go wrong when compiling
this sort of code:

  http://www.hpl.hp.com/personal/Hans_Boehm/misc_slides/c++mm.pdf

The problem of determining the correctness of a compiler's translation of a
piece of code containing C++0x concurrency primitives is not trivial, but
basically it's not our problem.  There exist (or will exist) some smart
checking tools for this sort of thing.

John



--
Derek M. Jones                         tel: +44 (0) 1252 520 667
Knowledge Software Ltd                 mailto:derek@knosof.co.uk
Source code analysis                   http://www.knosof.co.uk