define ATOMICOPS_COMPILER_BARRIER in platform.h

define ATOMICOPS_COMPILER_BARRIER in platform.h.
such as defined in atomicops_internals_[arch]_gcc.h

and use it in platform-[platform].cc

BUG=none
TEST=none

[Jakob Kummerow, 2012-06-08 14:58:09]

Thanks for the patch! It looks good to me (LGTM), but before I can land it, you
need to sign the Contributor License Agreement. See
http://code.google.com/p/v8/wiki/Contributing#The_small_print .

[takano32, 2012-06-08 22:32:30]

Thank you!
i chosoe electricity sign.
http://farm9.static.flickr.com/8160/7167514735_ae317bf289.jpg

this commit experience is very exciting for me.
this commit is trivial but i can understand process to contribute!

Thanks a lot.

[Jakob Kummerow, 2012-06-11 09:23:58]

Actually, this doesn't compile for me:
../src/platform-linux.cc: In static member function 'static void
v8::internal::OS::ReleaseStore(volatile AtomicWord*, v8::internal::AtomicWord)':
../src/platform-linux.cc:281:30: error: 'ATOMICOPS_COMPILER_BARRIER' was not
declared in this scope

I think what happens is: platform.h includes atomicops.h which includes
atomicops_internals_x86_gcc.h which defines a macro of the same name (and
contents!) and then undefs it after it's done.
We normally try not to let macros live beyond file boundaries, i.e. define it
where it's needed, then undef it. Doing this in many places doesn't mix well
with not doing it elsewhere ;-)

So, I don't think we can land this CL in its current form or with minor fixes. A
better way might be to move the definitions that want to use
ATOMICOPS_COMPILER_BARRIER to atomicops_internals_x86_gcc.h where that macro is
already available, but I haven't looked into whether that's easily possible.