> Please could you add a comment explaining that the mips_nanlegacy is there
> because of the #include of system headers that might not compile with
> -mnan=legacy? I agree that that's a good reason, but it's not obvious
> without a comment. (And without a comment this could start a precendent
> of things being skipped in cases where the mips.exp options machinery
> could be updated instead.)
>
True. Clarification added.
Ok for trunk?
Regards,
Robert
2015-02-02 Robert Suchanek <robert.sucha...@imgtec.com>
* gcc.target/mips/loongson-simd.c: Update comment to clarify the need
for mips_nanlegacy target.
diff --git a/gcc/testsuite/gcc.target/mips/loongson-simd.c
b/gcc/testsuite/gcc.target/mips/loongson-simd.c
index 949632e..9c3ebce 100644
--- a/gcc/testsuite/gcc.target/mips/loongson-simd.c
+++ b/gcc/testsuite/gcc.target/mips/loongson-simd.c
@@ -21,7 +21,10 @@ along with GCC; see the file COPYING3. If not see
/* { dg-do run } */
/* loongson.h does not handle or check for MIPS16ness or
microMIPSness. There doesn't seem any good reason for it to, given
- that the Loongson processors do not support either. */
+ that the Loongson processors do not support either. The effective target
+ mips_nanlegacy is required for a toolchain without the legacy NaN support
+ because inclusion of some system headers e.g. stdint.h will fail due to not
+ finding stubs-o32_hard.h. */
/* { dg-require-effective-target mips_nanlegacy } */
/* { dg-options "isa=loongson -mhard-float -mno-micromips -mno-mips16
-flax-vector-conversions" } */
