This is the mail archive of the
mailing list for the binutils project.
Re: [AArch64] Additional SVE instructions
- From: Yury Norov <ynorov at caviumnetworks dot com>
- To: Andrew Pinski <pinskia at gmail dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, binutils <binutils at sourceware dot org>, Richard Earnshaw <richard dot earnshaw at arm dot com>, Tristan Gingold <gingold at adacore dot com>, richard dot sandiford at arm dot com
- Date: Sat, 25 Feb 2017 00:22:30 +0530
- Subject: Re: [AArch64] Additional SVE instructions
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Yuri dot Norov at caviumnetworks dot com;
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <CA+=Sn1=8-MYKg12_-khv27WOQnDgaY=yuDWgc2L=2DhMLkfZiQ@mail.gmail.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On Fri, Feb 24, 2017 at 10:26:10AM -0800, Andrew Pinski wrote:
> On Fri, Feb 24, 2017 at 10:15 AM, Richard Sandiford
> <email@example.com> wrote:
> > Nick Clifton <firstname.lastname@example.org> writes:
> >> Hi Richard,
> >>> This patch supports some additions to the SVE architecture prior to
> >>> its public release.
> >>> Tested on aarch64-linux-gnu.
> >> Did you check both big-endian and little-endian ?
> > I have now :-) It's also been tested with users/ARM/sve-branch of GCC.
> >> (I have checked and
> >> I know that there are no problems, but I just want to make the point that
> >> it helps to know all the variations that you have tested. Hmm, I probably
> >> should have checked ilp32 as well...)
> > Not sure there's a specific ILP32 triplet yet for binutils.
> IIRC ILP32 testing for binutils is normally included with the default
> aarch64 target. We (Yury really) added a bunch of tests for ILP32 but
> I don't remember how many tests are there though.
I added ~15 tests specific for ILP32 relocation relaxations. They all
already enabled as part of ld testsuite. If I understand testing
machinery correctly, there's no way to rebuild tests in ILP32 mode
like we do in say glibc, and so the only way to increase ILP32 test
coverage is to write new tests were reasonable. This is out of scope
of the patch, for me.