On 21 May 2015 at 07:33, Sandra Loosemore <san...@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? Christophe. > -Sandra >
