On 10 March 2016 at 19:52, Yvan Roux wrote:
> On 10 March 2016 at 19:42, Edward Nevill wrote:
>>> /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
>>
>> Am
On 10 March 2016 at 19:42, Edward Nevill wrote:
>> /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
>
> Am I going mad, or does this just return the contents of t
> /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
Am I going mad, or does this just return the contents of the memory
location * 2.
ldaddal w0, w0, [x1]
Returns the
Hi Yvan,
On 9 March 2016 at 13:22, Yvan Roux wrote:
> Hi Ed,
>
> On 9 March 2016 at 14:02, Edward Nevill 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
> Also, is it worthwhile putting a prfm before the ldaxr. EG
There is already a thread upstream about this:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00508.html
I reject adding this to -mcpu=generic as it will hurt ThunderX more than it
will help. Prfm is single issue for ThunderX so it caus
Hi Ed,
On 9 March 2016 at 14:02, Edward Nevill wrote:
> Hi,
>
> I have been comparing the stock gcc 5.2 and the Linaro 5.2 (Linaro GCC
> 5.2-2015.11-1) and have noticed a difference with the __sync
> intrinsics.
>
> Here is the simple test case
>
> --- cut here ---
> int add_int(int add_value, in
