On 15 June 2016 at 10:45, Christophe Lyon <christophe.l...@linaro.org> wrote:
> On 9 June 2016 at 14:46, Jakub Jelinek <ja...@redhat.com> wrote:
>> On Thu, Jun 09, 2016 at 02:40:43PM +0200, Christophe Lyon wrote:
>>> > Bet it depends if this happens before the signal(SIGILL, sig_ill_handler);
>>> > call or after it. If before, then I guess you'd better rewrite the
>>> > long long a = 0, b = 1;
>>> > asm ("vorr %P0, %P1, %P2"
>>> > : "=w" (a)
>>> > : "0" (a), "w" (b));
>>> > if (a != 1)
>>>
>>> Of course you are right: it happens just before the call to signal,
>>> to build the sig_ill_handler address in r1.
>>>
>>> So it's not even a problem with rewriting the asm.
>>
>> Ugh, so the added options don't affect just vectorized code, but normal
>> integer only code?
>> check_vect is fragile, there is always a risk that some instruction is
>> scheduled before the call.
>
> Yes, here it's an instruction used to build a parameter of the call.
>
>> If you have working target attribute support, I think you should compile
>> check_vect with attribute set to some lowest common denominator that every
>> ARM CPU supports (if there is any, that is). Though most likely you'll need
>> to tweak the inline asm, because maybe "w" constraint won't be available
>> then.
>
> ARM does not support attribute/pragma cpu :(
>
> Here is a new patch version, which removes the hardcoded dg-do run directives,
> so that tests use compile or run depending on the result of
> check_vect_support_and_set_flags.
>
> On ARM, this first uses arm_neon_ok to detect the required flags, then
> depending on
> arm_neon_hw, it decides whether to dg-do run or compile.
>
> OK?
ping?
>
> Christophe
>
>> Jakub
