On 06/08/2011 03:17 AM, Joseph S. Myers wrote: > On Tue, 7 Jun 2011, Janis Johnson wrote: > >> These tests fail when multilib options use -mfpu=xxxx and override the >> -mfpu=neon-fp16 used for the test: >> >> g++.dg/ext/arm-fp16/arm-fp16-ops-5.C >> g++.dg/ext/arm-fp16/arm-fp16-ops-6.C >> gcc.dg/torture/arm-fp16-ops-5.c >> gcc.dg/torture/arm-fp16-ops-6.c >> gcc.target/arm/fp16-compile-vcvt.c >> >> The option -mfpu-neon-fp16 is added via "dg-add-options arm_neon_fp16" >> after an earlier "dg-require-effective-target arm_neon_fp16_ok". >> This patch modifies check_effective_target_arm_neon_fp16_ok_nocache to >> return 0 (causing the test to be skipped) if multilib flags include >> -mfpu= with a value other than neon-fp16. > > But I'd think they ought to work with any -mfpu= option supporting > half-precision instructions - that is, vfpv3-fp16, vfpv3-d16-fp16, > vfpv3xd-fp16, neon-fp16, vfpv4, vfpv4-d16, fpv4-sp-d16, neon-vfpv4 > (anything with "true" in the last field in arm-fpus.def; for the > testsuite, you can probably suppose anything -mfpu=*fp16*, > -mfpu=*fpv[4-9]*, -mfpu=*fpv[1-9][0-9]*). >
These tests look for specific instructions being generated and fail when the check is hacked up to allow other fp16 variants and not require neon. I'd like to use the original patch for this. OK? Janis