From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-451321-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 25589 invoked by alias); 12 May 2014 12:56:03 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 25558 invoked by uid 48); 12 May 2014 12:56:00 -0000
From: "ktkachov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61153] [ARM] vbic vorn tests fail
Date: Mon, 12 May 2014 12:56:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ktkachov at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61153-4-0cCnt9cxHx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61153-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61153-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-05/txt/msg01013.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153

--- Comment #3 from ktkachov at gcc dot gnu.org ---
> So maybe we should add some optimization level to the existing tests in the
> meantime?

Transforming them into something like

#include "arm_neon.h"

volatile int16x8_t arg0_int16x8_t;
volatile int16x8_t arg1_int16x8_t;

int16x8_t test_vbicQs16 (void)
{
  int16x8_t out_int16x8_t;

  return vbicq_s16 (arg0_int16x8_t, arg1_int16x8_t);
}

seems to work at -O2 (i.e. generates vbic and doesn't optimise away the whole
test), so it could be a way to go if the maintainers want it.

To be a bit pedantic, the ACLE spec doesn't strictly require the intrinsics
that the particular NEON instruction is generated, just that the functionality
is as defined in the spec (although the NEON instruction is likely to be the
optimal implementation of that functionality).

Do we plan to keep these scan-assembler tests? or go with just functional
tests?