[PATCH 13/14][ARM/AArch64 testsuite] Use gcc-dg-runtest in advsimd-intrinsics.exp

Christophe Lyon christophe.lyon@linaro.org
Tue May 26 19:12:00 GMT 2015


On 26 May 2015 at 18:25, Alan Lawrence <alan.lawrence@arm.com> wrote:
> Christophe Lyon wrote:
>>
>> On 22 April 2015 at 19:36, Alan Lawrence <alan.lawrence@arm.com> wrote:
>>>
>>> In the first revision of Christophe Lyon's advsimd-intrinsics tests,
>>> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00532.html , both
>>> gcc-dg-runtest (to assemble only) and c-torture-execute were used. In
>>> review
>>> the gcc-dg-runtest part was then dropped, and execution tests continued
>>> using c-torture-execute. However, c-torture-execute ignores e.g.
>>> dg-options
>>> directives in the individual test files, whereas gcc-dg-runtest does not.
>>>
>>> This patch switches to gcc-dg-runtest (with dg-do-what-default = "run")
>>> for
>>> all tests, allowing use of e.g. dg-options (in testsuite patch 3/3). This
>>
>>
>> Sandra has recently committed a slightly different patch.
>>
>> If you want to update your, here are few comments/questions:
>> - why do you add "-w" to additional_flags?
>
>
> Hmmm. Not sure now. I agree, it appears to work without, so will drop that.
>
>> - you changed the way we iterate over the tests, but this removes the
>> possiblity to actually execute only a subset of the available tests,
>> such as RUNTESTFLAGS=advsimd-intrinsics.exp=vadd.c
>
>
> I don't see this symptom - I am able to execute such subsets with either my,
> or Sandra's, advsimd-intrinsics.exp.

I didn't try to run with your patch, I thought it was an oversight of yours.

Sorry, indeed I've just checked that gcc-dg-runtest includes the filter.

>
> Is it that you have to check runtest_file_p because you are setting
> gcc_parallel_test_enable to 0?
>
> I'm doing more testing now, but I think I can drop my advsimd-intrinsics.exp
> changes altogether; I'll post an updated patch series shortly.
>
> In the meantime I'm curious as to why you found the gcc_parallel_test_enable
> necessary? (And is it safe to reset it to 1 afterwards, rather than to a
> saved value?)
See https://gcc.gnu.org/ml/gcc/2014-10/msg00081.html

>
> TYVM for your other comments and review - I will incorporate all into my
> next revision.

Thanks.

>
> Thanks, Alan
>



More information about the Gcc-patches mailing list