Hi Yvan,
On 9 March 2016 at 13:22, Yvan Roux <yvan.r...@linaro.org> wrote:
> Hi Ed,
>
> On 9 March 2016 at 14:02, Edward Nevill <edward.nev...@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.
>
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01989.html
>
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.
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
