Re: ARM: __sync_synchronize does not generate code

[rridge at csclub dot uwaterloo dot ca (Ross Ridge)]

Ross Ridge writes:
> 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.

Andrew Haley writes:
> 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.

In the first case, where there is no hardware memory barrier needed,
your patch would cause a working program not to compile.  In the second
case, outside of Linux, a broken program wouldn't be fixed.  It would
get an error now, but it's one that says the compiler is broken.

All-in-all your patch might be better than before, but I thought it
worth mentioning that __sync_synchronize() did have an effect on code
that you seemed to be unware of, and that behaviour could be correct on
some targets.  The i386 port had the same problem, but that was fixed
by emitting a memory barrier instruction on all targets.  Programs that
worked with the old behaviour didn't actually need a hardware barrier
continued to work.

					Ross Ridge