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.
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?