From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16820 invoked by alias); 7 Jun 2016 09:28:26 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 16810 invoked by uid 89); 7 Jun 2016 09:28:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=lyon, Lyon, H*i:ZFF, H*f:sk:CAKdteO X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 07 Jun 2016 09:28:25 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8A6957F352; Tue, 7 Jun 2016 09:28:23 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-51.ams2.redhat.com [10.36.116.51]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u579SL6j011340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 7 Jun 2016 05:28:22 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u579SJ9D014456; Tue, 7 Jun 2016 11:28:19 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u579SGOp014455; Tue, 7 Jun 2016 11:28:16 +0200 Date: Tue, 07 Jun 2016 09:28:00 -0000 From: Jakub Jelinek To: Christophe Lyon Cc: Richard Biener , Ilya Enkovich , gcc-patches Subject: Re: [PATCH] Fix SLP wrong-code with VECTOR_BOOLEAN_TYPE_P (PR tree-optimization/71259) Message-ID: <20160607092816.GO7387@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20160111171343.GB18720@tucnak.redhat.com> <20160603173343.GM7387@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-06/txt/msg00465.txt.bz2 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