Re: [Patch ARM/testsuite 00/22] Neon intrinsics executable tests

[Christophe Lyon <christophe dot lyon at linaro dot org>]

On 11 June 2014 00:03, Ramana Radhakrishnan <ramana.gcc@googlemail.com> wrote:
> On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
> <christophe.lyon@linaro.org> wrote:
>> This is patch series is a more complete version of the patch I sent
>> some time ago:
>> https://gcc.gnu.org/ml/gcc-patches/2013-10/msg00624.html
>>
>> I have created a series of patches to help review.  The 1st one adds
>> some documentation, the common .h files defining helpers used in the
>> actual tests, and two real tests (vaba and vld1) to show how the
>> various macros are used.
>>
>> The next patches add other tests (grouped when they use a common
>> framework).
>>
>> Looking at the .exp file, you'll notice that the tests are performed twice:
>> * once using c-torture-execute to make sure they execute correctly
>>   under various levels of optimization. In this case dejagnu
>>   directives embedded in each .c test file are ignored.
>>
>> * once using gcc-dg-runtest, which enables compiling with various
>>   optimization levels and scanning the generated assembly for some
>>   code sequences. Currently, only the vadd test contains some
>>   scan-assembler-times directives, as an example. We can add such
>>   directives to other tests later.
>
>>
>> Regarding the results of these tests on target
>> arm-none-linux-gnueabihf, note that:
>> * vclz tests currently fail at optimization levels starting with -O1
>> * vqadd test fails when compiled with -Os
>> * vadd scan-assembler fails for vadd.i64 (because the compiler uses
>>   core registers instead of Neon ones. Not sure if this should be
>>   considered as a bug or if the test should be changed)
>> * this gives 1164 PASS and 18 FAIL
>>
>
> I am a bit ambivalent between getting folks to add scan-assembler
> tests here and worrying between this and getting the behaviour
> correct. Additionally if you add the complexity of scanning for
> aarch64 as well this starts getting messy.
>

This feature wasn't in my testsuite originally, I added it recently
after your suggestion.
Indeed it's getting messy, not sure what the best way to proceed (and
that's why I only added the scan-assembler as an example in one test
:-)


> At this point I'm going to wait to see if any of the testsuite
> maintainers step in and comment and if not I'll start looking at this
> properly early next week.
>
OK thanks.

Christophe.