This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: why the barrier() can not take effect?


On 12/24/2010 12:02 PM, Parmenides wrote:
I don't know why you'd expect a difference, really. Try this:

I just want to know precisely what measures the gcc take when a asm statement including a clobber of "memory", rather merely than a general description in the gcc manual. In Linux kernel code, the barrier() appears frequently in some kernel funcitons. So, I wish to get the exactly meaning of the barrier().

int s = 0;

So, just the variables which might be modified by some outer code unpredictable, such as interrupt handlers, other processes, etc, will be given more cares by the gcc. But, we need not to worry about whether or not a local variable in some function is consistent with the corresponding register, because it is impossible that a local variable will be modified outside the current code. Is that true?

This is defined by the C standard itself. The compiler *knows* that a local variable can only be modified by the code in the scope where it is defined, unless that code passes the address of the variable to code outside that scope. If the code does pass the address of the variable elsewhere, the variable won't be located in a register. Thus, variables that are candidates to be located in registers are also guaranteed to not be affected by memory barriers and other such operations on memory.


--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.digium.com & www.asterisk.org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]