| Message ID | 4DEECB2D.9000403@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
On Jun 7, 2011, at 6:06 PM, Janis Johnson wrote: > These tests fail when multilib options use -mfpu=xxxx and override the > -mfpu=neon-fp16 used for the test: > OK for trunk and 4.6 branch? Ok, but watch for comments from arm people.
On 06/07/2011 06:29 PM, Mike Stump wrote: > On Jun 7, 2011, at 6:06 PM, Janis Johnson wrote: >> These tests fail when multilib options use -mfpu=xxxx and override the >> -mfpu=neon-fp16 used for the test: > >> OK for trunk and 4.6 branch? > > Ok, but watch for comments from arm people. Yes, I'm hoping to hear from them. Janis
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]*).
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]*). > If someone is testing with a multilib using "-mfpu=vfpv4" they're probably also testing with a multilib that doesn't use -mfpu, so they're running the test somewhere. Do we want to run these tests for all multilibs that use one of those,or is it enough to only use -mfpu=neon-fp16 for the tests? I think we're going to be looking at that question for a lot of individual tests, and the answer will vary depending on the test. I want to clean up these tests so they can be run cleanly with a lot of multilibs so that real failures can be noticed, so I really appreciate this discussion. The mips tests use their own scheme to override multilib options, but I find it confusing and would rather do something else, unless the arm developers want to use that for arm tests as well. Janis
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
On 10/06/11 00:43, Janis Johnson wrote: > 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 > > That sounds like you might have uncovered a bug. Can you provide some more detail? Running (manually) gcc.target/arm/fp16-compile-vcvt.c with "-O -mfpu=vfpv4 -mfp16-format=ieee" gives the instructions required by the scanner. R.
Index: gcc/testsuite/lib/target-supports.exp =================================================================== --- gcc/testsuite/lib/target-supports.exp (revision 174764) +++ gcc/testsuite/lib/target-supports.exp (working copy) @@ -1954,6 +1954,11 @@ global et_arm_neon_fp16_flags set et_arm_neon_fp16_flags "" if { [check_effective_target_arm32] } { + # Multilib flags that include -mfpu would override the flags set here; + # skip them. + if [check-flags [list "" { *-*-* } { "-mfpu=*" } { "-mfpu=neon-fp16" } ]] { + return 0 + } # Always add -mfpu=neon-fp16, since there is no preprocessor # macro for FP16 support. foreach flags {"-mfpu=neon-fp16" "-mfpu=neon-fp16 -mfloat-abi=softfp"} {