Hi Yvan,
On 9 March 2016 at 13:22, Yvan Roux yvan.roux@linaro.org wrote:
Hi Ed,
On 9 March 2016 at 14:02, Edward Nevill edward.nevill@linaro.org wrote:
Hi,
Why the extra (unnecessary?) memory barrier?
This is because Linaro gcc-5-branch is in sync with FSF gcc-5-branch which contains a fix for this PR : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
As explained in the bugzilla and the patch submission the restriction are stonger on __sync builtins than on __atomic ones.
Thanks for that, obviously we should be using the __atomic versions in Java as I dont believe Java requires a memory barrier.
One curiosity, I recompiled for 8.1 LSE using the Linaro gcc 5.2 and I got the following
/usr/local/linare-gcc-5.2/bin/gcc -S -O3 -march=armv8-a+lse test.c
add_int: ldaddal w0, w0, [x1] add w2, w0, w0 mov w0, w2 ret
Why no memory barrier here? As far as I am aware the ldaddal has only acquire and release semantics, it does not implement a full barrier?
All the best, Ed.