Comments on: Volatile Structs Are Broken http://blog.regehr.org/archives/274 Thu, 23 May 2013 02:13:55 +0000 hourly 1 http://wordpress.org/?v=3.5.1 By: regehr http://blog.regehr.org/archives/274/comment-page-1#comment-1337 regehr Thu, 07 Oct 2010 06:27:43 +0000 http://blog.regehr.org/?p=274#comment-1337 Hi Xilun- Yes, what constitutes an access to a volatile variable is implementation defined. But you have missed the fact that all reasonable C implementations consider a read from a volatile variable to be a read access and a write to a volatile variable to be a write access. We discussed this in some detail in the EMSOFT paper linked from the post.

This is a real bug. As I noted in an update, it was fixed in LLVM within hours of being reported. I expect that it will get fixed in GCC as well.

]]> By: xilun http://blog.regehr.org/archives/274/comment-page-1#comment-1334 xilun Wed, 06 Oct 2010 22:37:17 +0000 http://blog.regehr.org/?p=274#comment-1334 Maybe this was different with C90 but C99 indeed does not seem to mandate generation of assembly instructions reading then storing back g_18: “6.7.3 Type qualifiers [...] What constitutes an access to an object that has volatile-qualified type is implementation-defined.”

So while IMO g_18.f0 = g_18.f0 * 2; should clearly generate load, mul, then store instructions, implementing func1() as a nop seem to be compliant with both 5.1.2.3 and 6.7.3. This is also consistent with the only clear requirement for volatiles: to be usable for signalisation between signals handlers and the rest of the program.

(Even though a note in C99 says that volatile “may be used to describe an object corresponding to a memory-mapped input/output port”, this obviously can only happen on systems where all bus access are strongly ordered throughout every hardware layer, otherwise the order of instructions generated by gcc would be meaningless in regard with what happen on the bus — and this is not the case for x86, and now more and more rare even on embedded systems.)

So maybe the only question that remains is: does “rep ret” executes as “ret” (and does so on all targeted x86 cpus). If this is not the case, this clearly is a bug. Otherwise, probably not.

]]>