[LLVMdev] qualitative comparison of correctness of llvm and gcc

[Duncan Sands]

Hi John,

> > does this also check that writes are atomic: that they are performed in
> > one processor operation?
> 
> Can you elaborate a bit?  I don't think volatile has any atomicity 
> requirements.  Of course I can make a struct, an int128_t, or whatever 
> volatile (on AVR even an int16_t is updated non-atomically!).

that's not entirely true in practice: if I do a 32 bit volatile write
to a memory-mapped i/o location, then I'd be annoyed if that got turned
into four 8 bit volatile writes.  And the hardware might react funny as
well!  Also, because languages like C currently only have a concept of
a volatile write and no concept of an atomic write (as far as I know),
I suspect it is common practice to use a volatile write of a size that
the processor is known to be able to perform atomically, and expect it
to end up as that atomic write in the final assembler (eg: a write of
a double should not be turned into two i32 writes on x86-32).  So I think
it is reasonable to expect LLVM to generate atomic reads and writes for
variables marked volatile if that can be done in a straightforward way
on the platform.  So my question is: are you testing whether LLVM does
in fact do this?  I appreciate that the C standard does not require it
(AFAIK).

> Lack of atomicity is one of many problems with using volatile as a basis 
> for creating correct systems code...

The Ada language has a proper notion of atomic write, but the gcc internal
language does not (AFAIK), presumably due to the C-centric origins of gcc.
So Ada marks the write "volatile", and generates a compile-time error if
the write cannot reasonably be atomic on the target machine.  For example,
it allows a double to be atomic (but not an i64) on x86-32.

Ciao,

Duncan.