[SLOF] [PATCH 3/4] fbuffer: Implement MRMOVE as an accelerated primitive

[Thomas Huth]

On 10/09/15 14:00, Nikunj A Dadhania wrote:
> Thomas Huth <thuth at redhat.com> writes:
> 
>> On 09/09/15 13:37, Nikunj A Dadhania wrote:
>>> Thomas Huth <thuth at redhat.com> writes:
>>>
>>>> On 09/09/15 13:05, Nikunj A Dadhania wrote:
>>>>> Thomas Huth <thuth at redhat.com> writes:
>>>>>
>>>>>> On 09/09/15 08:45, Nikunj A Dadhania wrote:
...
>>>>>>> TCG seem to be broken with this new series, git bisect pointed to:
>>>>>>>
>>>>>>> 59a135e fbuffer: Implement MRMOVE as an accelerated primitive
>>>>>>>
>>>>>>> I havent looked into detail of why its failing though.
...
>>
>> I've did some more tests, and it occurs for me, too, when I use the ATC
>> compiler instead of my normal cross-compiler from my distro!
> 
> I am using:
> 
> $ powerpc64-linux-gnu-gcc --version
> powerpc64-linux-gnu-gcc (GCC) 5.1.1 20150422 (Red Hat Cross 5.1.1-1)

Ok, I've also install ATC 7.0, and with that it seems to be working
fine, too.

So we've got:
- RHEL 7.1 cross-compiler (gcc 4.8.1) : working
- AT 7.0 cross-compiler (gcc 4.8.5) : working
- AT 8.0 cross-compiler (gcc 4.9.3) : not working
- Your (Fedora?) cross-compiler (gcc 5.1.1) : not working

I guess newer GCCs are using some kind of additional optimization that
clashes with a hidden SLOF bug - triggered by my recent patches.
I've stared at the code of my recent patches for quite a while now, but
I can't see anything wrong in there. Even worse, when you add some
printf statements in _FASTRMOVE for example, you can see that the code
is even not called before the "failed to include fbuffer.fs" error occurs!

So this is really a confusing bug. Of course feel free to revert my
patches if you like ... but unless we're sure that the bug is in my
patches, this might also just temporarily solve this issue...

 Thomas