[patch, testsuite, ARM] don't try to execute advsimd-intrinsics tests on hardware without NEON

Christophe Lyon christophe.lyon@linaro.org
Thu May 21 10:31:00 GMT 2015

On 21 May 2015 at 07:33, Sandra Loosemore <sandra@codesourcery.com> wrote:
> ARM testing shares the AArch64 advsimd-intrinsics execution tests.  On ARM,
> though, the NEON support being tested is optional -- some arches are
> compatible with the NEON compilation options but hardware available for
> testing might or might not be able to execute those instructions. In
> arm-none-eabi testing of a long list of multilibs, I found that this problem
> caused some of the multilibs to get stuck for days because every one of
> these execution tests was wandering off into the weeds and timing out.
> The vect.exp tests already handle this by setting dg-do-what-default to
> either "run" or "compile", depending on whether we have target hardware
> execution support (arm_neon_hw) for NEON, or only compilation support
> (arm_neon_ok).  So, I've adapted that logic for advsimd-intrinsics.exp too.

Indeed it makes sense.

> It also appeared that the main loop over the test cases was running them all
> twice with the torture options -- once using c-torture-execute and once
> using gcc-dg-runtest.  I deleted the former since it appears to ignore
> dg-do-what-default and always try to execute no matter what.  My dejagnu-fu
> isn't the strongest and this is pretty confusing to me.... am I missing
> something here?  Otherwise, OK to commit?

As noted by Alan in https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01348.html
the sets of options covered by gcc-dg-runtest and c-torture-execute
are slightly different.

That was the reason I kept both.
We can probably live with no longer testing "-Og -g" as Alan says.
OTOH, are the 2 option sets supposed to be the same, or are there any
plans to make them differ substantially  in the future?


> -Sandra

More information about the Gcc-patches mailing list