From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-411883-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 45235 invoked by alias); 28 Oct 2015 19:37:20 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 45224 invoked by uid 89); 28 Oct 2015 19:37:19 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-io0-f178.google.com
Received: from mail-io0-f178.google.com (HELO mail-io0-f178.google.com) (209.85.223.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 28 Oct 2015 19:37:18 +0000
Received: by iodd200 with SMTP id d200so22355453iod.0        for <gcc-patches@gcc.gnu.org>; Wed, 28 Oct 2015 12:37:16 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.33.211 with SMTP id h202mr19416571ioh.108.1446061036346; Wed, 28 Oct 2015 12:37:16 -0700 (PDT)
Received: by 10.36.209.7 with HTTP; Wed, 28 Oct 2015 12:37:16 -0700 (PDT)
In-Reply-To: <1446050893.7184.0.camel@oc8801110288.ibm.com>
References: <20151002135921.GE26618@msticlxl57.ims.intel.com>	<mvmbnbrmcrw.fsf@hawking.suse.de>	<CAMbmDYb9MhPrrs+L50XAQA8N_aYvd+TACEQ-BFbRtduPjH7V+g@mail.gmail.com>	<mvm7fmfmbnv.fsf@hawking.suse.de>	<20151022162105.GB23452@msticlxl57.ims.intel.com>	<CAFiYyc3aRo-=kW-qD3xCaCkTVkJ=Zbaq-pZhvAd7XJo=QSpsxg@mail.gmail.com>	<20151023111240.GC23452@msticlxl57.ims.intel.com>	<CAFiYyc3oG_N-KXcAEYcmKkrogngrLe=4j3ag5Fir_de6uKda3g@mail.gmail.com>	<CAKdteOY_bHt4cOr-b2UyYpt3n-XvdYz2kW1LdwJv_kR1D0j7zA@mail.gmail.com>	<1446050893.7184.0.camel@oc8801110288.ibm.com>
Date: Wed, 28 Oct 2015 19:39:00 -0000
Message-ID: <CAMbmDYa9RBBVqA0oAyPn4g6CU-1ARwpfxK2=LWtS9Lq+feJLgw@mail.gmail.com>
Subject: Re: [Boolean Vector, patch 1/5] Introduce boolean vector to be used as a vector comparison type
From: Ilya Enkovich <enkovich.gnu@gmail.com>
To: Bill Schmidt <wschmidt@linux.vnet.ibm.com>
Cc: Christophe Lyon <christophe.lyon@linaro.org>, gcc-patches <gcc-patches@gcc.gnu.org>
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes
X-SW-Source: 2015-10/txt/msg03104.txt.bz2

Seems the problem occurs in this check in expand_vector_operations_1:

  /* A scalar operation pretending to be a vector one.  */
  if (VECTOR_BOOLEAN_TYPE_P (type)
      && !VECTOR_MODE_P (TYPE_MODE (type))
      && TYPE_MODE (type) != BLKmode)
    return;

This is to filter out scalar operations on boolean vectors.
The problem here is that TYPE_MODE (type) doesn't return
V4SImode assigned to the type but calls vector_type_mode
instead which tries to find an integer mode for it and returns
TImode. This causes function exit and we don't expand vector
comparison.

Suppose simple option to fix it is to change default get_mask_mode
hook to return BLKmode in case chosen integer vector mode is not
vector_mode_supported_p.

Thanks,
Ilya

2015-10-28 19:48 GMT+03:00 Bill Schmidt <wschmidt@linux.vnet.ibm.com>:
> On Wed, 2015-10-28 at 14:44 +0100, Christophe Lyon wrote:
>> Hi,
>>
>> Since r229128, I see:
>> FAIL: c-c++-common/torture/vector-compare-1.c   -O0  execution test
>> on arm targets, such as arm-none-eabi.
>
> Likewise for powerpc64le-linux-gnu.  The test produces:
>
> 0 != ((1.000000 > 0.000000 ? -1 : 0) FAIL: c-c++-common/torture/vector-compare-1
> .c   -O0  execution test
>
>>
>> Christophe.
>>
>
>