[cfe-dev] [RFC] add Function Attribute to disable optimization

Joshua Cranmer pidgeot18 at gmail.com
Mon Jun 17 22:16:12 PDT 2013


On 6/17/2013 7:23 PM, Jeffrey Walton wrote:
> Microsoft was not the problem - it was GCC since the only use of 
> volatile is memory mapped hardware. 

That is a gross misrepresentation of volatile, I think. The intent of 
volatile is that it represents memory-mapped I/O registers. The 
practical effect of volatile is that it prohibits optimization of loads 
and stores--it makes sure that when you access that pointer, the 
appropriate LD or ST instruction is actually inserted in the output 
assembly code. I think you'd be hard-pressed to find a compiler writer 
who would disagree with that latter statement.

The real issue comes with multiple threads. Since C99 pretends that 
multiple threads don't exist, POSIX ducks the issue, and x86 has a 
strong memory model, it is very easy to fall into the trap that a 
volatile memory access is sufficient to guarantee cross-thread 
visibility. Since most discussion about volatile comes up with respect 
to this issue, the discussion mostly tends to be summarized as "don't 
use volatile for that because it's not intended for that; it's designed 
for memory-mapped I/O"

Another reason why it's untrue is found in ยง7.14.1: volatile 
sig_atomic_t variables are the only variables whose values are valid 
during execution of a signal handler. If you volatile as merely 
programmer intent of "make sure this store happens when I say it does," 
this is a very natural thing to expect from C.

> volatile void clean_memory(volatile void* dest, size_t len)
> {
>      volatile unsigned char* p;
>      for(p = (volatile unsigned char*)dest; len; dest[--len] = 0)
>        ;;
> }
>
> Because the pointers above ('dest' and `p`) were not memory mapped
> addresses, the GCC folks consider it an abuse.

Did you actively ask them this question, or are you surmising from what 
you've read on lists? For your use case--zeroing out memory so people 
can't sneak read your memory map [1]--I would consider it a valid use 
myself; I would be surprised if a compiler developer disagreed with this 
solely on the basis that it's not clearing out a memory mapped address 
space.

[1] The link has crypto in it, so I'm guessing as to its use from that 
context.

-- 
Joshua Cranmer
News submodule owner
DXR coauthor




More information about the cfe-dev mailing list