> On Oct 31, 2018, at 5:47 PM, Joseph Myers <jos...@codesourcery.com> wrote:
>
> On Wed, 31 Oct 2018, Paul Koning wrote:
>
>> So you mean, add a new keyword (say, "ieee") to dg-effective-target that
>> means "run this test only on ieee targets"?
>
> Note that different tests may need different IEEE features, though some
> such cases are already handled specially anyway - so be clear on what
> target properties such a keyword actually relates to. (E.g.
> fenv_exceptions already exists for tests needing floating-point
> exceptions; tests that don't work on SPU because of the way its
> single-precision format deviates from IEEE are skipped specifically for
> spu-*-*; tests handling IBM long double specially as needed.)
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
I can add a general "ieee" test. I've also found some test cases that depend
on things like the width of exponent and mantissa, and are written to match
what IEEE does. They may well be valid for some other float formats, so saying
they require IEEE might not be the best answer. For example
gcc.dg/tree-ssa/sprintf-warn-10.c which has checks like this:
T1 ("%.*a", 0); /* { dg-warning "between 3 and 10 bytes" } */
Many of those numbers come out different on pdp11, partly because it's a 16 bit
platform (so the upper bound is never > 32767) and partly because the float
format has different field widths than IEEE.
Another case is tests that refer to infinite, which some float formats don't
have. Or "not a number"; pdp11 has some flavors of that but not all that IEEE
has. Should I try to add various other float features, like "infinite", "nan",
"quiet-nan", "signaling-nan"?
Given Rainer's comment that dg-effective-target ieee and dg-add-options ieee
should be separate, should I add dg-effective-target ieee to every test that
currently says dg-add-options ieee? Or leave that for others to do
selectively? It feels like it can be applied everywhere, but I may be missing
something.
paul
