This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: ARM: __sync_synchronize does not generate code
- From: Andrew Haley <aph at redhat dot com>
- To: Ross Ridge <rridge at csclub dot uwaterloo dot ca>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 13 Aug 2009 10:24:12 +0100
- Subject: Re: ARM: __sync_synchronize does not generate code
- References: <20090812230803.F166573F74@caffeine.csclub.uwaterloo.ca>
Ross Ridge wrote:
> Andrew Haley writes:
>> ... if someone has deliberately called __sync_synchronize() they
>> presumably expect something to happen at runtime as a result.
>
> Even if __sync_synchronize() doesn't generate an instruction it should
> still affect generated code. It acts as a memory barrier at the compiler
> level.
Yes. This part works. What was wrong was that no memory barrier
was being emitted.
> If there isn't any way to implement a useful memory barrier on a
> given target (the "NOP" case Richard Earnshaw mentioned), then the
> existing behavior is actually what I'd expect. I'd never expect GCC to
> emit a libcall to an undefined function.
Even if it would cause real programs to fail? I find that rather
hard to believe. I certainly would rather have some notice that I
needed to implement a memory barrier.
Andrew.