Re: [PATCH] Fix SLP wrong-code with VECTOR_BOOLEAN_TYPE_P (PR tree-optimization/71259)

[Jakub Jelinek <jakub@redhat.com>]

On Tue, Jun 07, 2016 at 11:23:01AM +0200, Christophe Lyon wrote:
> > --- gcc/testsuite/gcc.dg/vect/pr71259.c.jj      2016-06-03 17:05:37.693475438 +0200
> > +++ gcc/testsuite/gcc.dg/vect/pr71259.c 2016-06-03 17:05:32.418544731 +0200
> > @@ -0,0 +1,28 @@
> > +/* PR tree-optimization/71259 */
> > +/* { dg-do run } */
> > +/* { dg-options "-O3" } */

Would changing this from dg-options to dg-additional-options help for the
ARM issues?
check_vect () is the standard way for testing for HW vectorization support
and hundreds of tests use it.

> > +/* { dg-additional-options "-mavx" { target avx_runtime } } */
> > +
> > +#include "tree-vect.h"
> > +
> > +long a, b[1][44][2];
> > +long long c[44][17][2];
> > +
> > +int
> > +main ()
> > +{
> > +  int i, j, k;
> > +  check_vect ();
> > +  asm volatile ("" : : : "memory");
> > +  for (i = 0; i < 44; i++)
> > +    for (j = 0; j < 17; j++)
> > +      for (k = 0; k < 2; k++)
> > +       c[i][j][k] = (30995740 >= *(k + *(j + *b)) != (a != 8)) - 5105075050047261684;
> > +  asm volatile ("" : : : "memory");
> > +  for (i = 0; i < 44; i++)
> > +    for (j = 0; j < 17; j++)
> > +      for (k = 0; k < 2; k++)
> > +       if (c[i][j][k] != -5105075050047261684)
> > +         __builtin_abort ();
> > +  return 0;
> > +}
> >
> 
> This new test fails on ARM targets where the default FPU is not Neon like.
> The error message I'm seeing is:
> In file included from
> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/gcc.dg/vect/pr71259.c:6:0:
> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/gcc.dg/vect/tree-vect.h:
> In function 'check_vect':
> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/gcc.dg/vect/tree-vect.h:65:5:
> error: inconsistent operand constraints in an 'asm'
> 
> Well, the same error message actually appears with other tests, I did
> notice this one because
> it is a new one.
> 
> The arm code is:
>     /* On some processors without NEON support, this instruction may
>        be a no-op, on others it may trap, so check that it executes
>        correctly.  */
>     long long a = 0, b = 1;
>     asm ("vorr %P0, %P1, %P2"
>          : "=w" (a)
>          : "0" (a), "w" (b));
> 
> ... which has been here since 2007 :(
> 
> IIUC, its purpose is to check Neon availability, but this makes the
> tests fail instead of
> being unsupported.
> 
> Why not use an effective-target check instead?

	Jakub