Re: ARM: __sync_synchronize does not generate code

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

Andrew Haley writes:
>What else would you have gcc do?  Failing silently to emit a necessary
>barrier is not better than causing a program not to compile.

Again, it's better in the case where the hardware barrier isn't necessary.
Outside of Linux, your patch will break any existing code that uses
__sync_synchronize() and works correctly.  GCC has had this behaviour
across several releases on many ports, so such code is not that unlikely
to exist.  Again, all-in-all it might be better this way, but from a
users perspective this is going to look like a regression, especially
given the error that results.

>Why on Earth did you think anyone was unaware of the memory barrier?

I thought you were unware that __sync_synchronize() affects code
generation because you said in your orignal post that "it does not
do anything".

>The point is that on the ARM you need kernel support to do the right
>thing, at least in a program that is portable across all variants.  If
>it were possible to emit some instructions to do a memory barrier,
>then gcc would do so.

Then it would better for gcc to give an error that indicated that fact.
Developers would be more likely to realize that they're doing something
wrong, not the compiler.  If they see a undefined error when using a a
compiler intrinsic that only exists to be implemented by the compiler,
they're not going think that they're expected to implement it themselves.
They're more likely to just go back to a "working" version of the
compiler.

					Ross Ridge