On Tue, May 10, 2016 at 2:02 PM, Christophe Lyon
<christophe.l...@linaro.org> wrote:
> On 9 May 2016 at 15:34, Christophe Lyon <christophe.l...@linaro.org> wrote:
>> On 9 May 2016 at 15:29, Jeff Law <l...@redhat.com> wrote:
>>> On 05/09/2016 01:37 AM, Christophe Lyon wrote:
>>>
>>>>
>>>> Hi,
>>>> After this merge, I'm seeing lots of timeouts on arm (using QEMU).
>>>> Is this "expected"? (as in: should I increase my timeout value)
>>>
>>> I wouldn't say it's expected; this is the first time Cilk+ has been
>>> supported on ARM. It could be a bug in the ARM support in the runtime, an
>>> ARM compiler bug or even a bug in the ARM QEMU support.
>>>
>>> Probably the first step is to see if it's working properly on real hardware.
>>> That would at least allow us to eliminate QEMU from the equation if it's
>>> failing in the same manner on a real machine.
>>>
>> OK, I'll check that.
>> I wanted to know if I was missing something obvious.
>>
>
> I've tested in an armhf chroot on an armv8 machine, and I saw SIGILL errors
> on:
> mcr 15, 0, r3, cr7, cr10, {4}
> which is how __cilkrts_fence is implemented in
> ../libcilkrts/runtime/config/arm/os-fence.h
At first glance I'd ask why this shouldn't be __atomic_thread_fence or
__atomic_signal_fence ( SEQ_CST) if that's what they want here and
then it will work (TM) regardless of architecture levels.
regards
Ramana
> This instruction is not supported anymore on armv8. Recent arm64 kernels
> have handlers for it.
>
> So we may want the implementation to be conditional, or prefer to rely on
> kernel support.
>
> In the mean time, I am going to disable cilkplus in my validations, as it
> is causing too much noise in the results.
>
> Christophe.
>
>
>>> Jeff
>>>
