dg-add-options ieee ?

[Paul Koning]

I see some test cases that say dg-add-options ieee. That apparently means: pretend we have IEEE float even when the target does not.

What is the point of doing that? On non-IEEE targets such test cases fail -- at least they do on pdp11. Instead I'd expect a check that skips these tests if not IEEE. There is a subdirectory for IEEE tests under gcc.c-torture, though not under gcc.dg.

I can just put a target specific dg-skip-if in these files, but I'm curious why dg-add-options was used.

paul

[Segher Boessenkool]

Post by Paul Koning
I see some test cases that say dg-add-options ieee. That apparently means: pretend we have IEEE float even when the target does not.

It means:

(from testsuite/lib/target-supports.exp)

===
# Add to FLAGS all the target-specific flags needed to enable
# full IEEE compliance mode.

proc add_options_for_ieee { flags } {
if { [istarget alpha*-*-*]
|| [istarget sh*-*-*] } {
return "$flags -mieee"
}
if { [istarget rx-*-*] } {
return "$flags -mnofpu"
}
return $flags
}
===

i.e. add those options that make the floating point IEEE compliant.
If your target cannot do that, it should skip the tests that need IEEE float
(and if it can do it, but it is (possibly) not the default, code needs to
be added here for your target).

Post by Paul Koning
What is the point of doing that? On non-IEEE targets such test cases fail -- at least they do on pdp11. Instead I'd expect a check that skips these tests if not IEEE. There is a subdirectory for IEEE tests under gcc.c-torture, though not under gcc.dg.
I can just put a target specific dg-skip-if in these files, but I'm curious why dg-add-options was used.

On some targets IEEE float is not the default, but those targets can still
do it if you pass certain options.


Segher

[Paul Koning]

Post by Segher Boessenkool

Post by Paul Koning
I see some test cases that say dg-add-options ieee. That apparently means: pretend we have IEEE float even when the target does not.

(from testsuite/lib/target-supports.exp)
===
# Add to FLAGS all the target-specific flags needed to enable
# full IEEE compliance mode.
...
i.e. add those options that make the floating point IEEE compliant.
If your target cannot do that, it should skip the tests that need IEEE float
(and if it can do it, but it is (possibly) not the default, code needs to
be added here for your target).

Post by Paul Koning
...

On some targets IEEE float is not the default, but those targets can still
do it if you pass certain options.
Segher

Ok, thanks. So adding a dg-skip-if for my target is indeed correct. Will do so.

paul

[Rainer Orth]

Hi Paul,

Post by Paul Koning
Ok, thanks. So adding a dg-skip-if for my target is indeed correct. Will do so.

please don't: since this is going to be common, please add a
corresponding effective-target keyword instead, together with
sourcebuild.texi documentation. That's far more expressive than
explicit target lists.

Thanks.
Rainer

[Paul Koning]

Post by Rainer Orth
Hi Paul,

Post by Paul Koning
Ok, thanks. So adding a dg-skip-if for my target is indeed correct. Will do so.

please don't: since this is going to be common, please add a
corresponding effective-target keyword instead, together with
sourcebuild.texi documentation. That's far more expressive than
explicit target lists.
Thanks.
Rainer

So you mean, add a new keyword (say, "ieee") to dg-effective-target that means "run this test only on ieee targets"?

Another approach might be to have dg-add-options ieee mean what it does today, but also have it skip the test for non-ieee capable targets. Or is that undesirable because it muddles the meaning of the dg-add-options keyword? I figure it would make sense because any test that has dg-add-options ieee by definition should be skipped by any target that can't do ieee at all.

paul

[Rainer Orth]

Hi Paul,

Post by Paul Koning

Post by Rainer Orth
Hi Paul,

Post by Paul Koning
Ok, thanks. So adding a dg-skip-if for my target is indeed correct.
Will do so.

please don't: since this is going to be common, please add a
corresponding effective-target keyword instead, together with
sourcebuild.texi documentation. That's far more expressive than
explicit target lists.
Thanks.
Rainer

So you mean, add a new keyword (say, "ieee") to dg-effective-target that
means "run this test only on ieee targets"?

right.

Post by Paul Koning
Another approach might be to have dg-add-options ieee mean what it does
today, but also have it skip the test for non-ieee capable targets. Or is
that undesirable because it muddles the meaning of the dg-add-options
keyword? I figure it would make sense because any test that has
dg-add-options ieee by definition should be skipped by any target that
can't do ieee at all.

No, that's not how things are supposed to work. Look at c99_runtime for
example: we have both

dg-require-effective-target c99_runtime

which checks if the targets supports a C99 runtime, and

dg-add-options c99_runtime

to add special options for targets that need them.

I've no idea why this isn't the case for ieee today.

Rainer

[Jeff Law]

Post by Rainer Orth
Hi Paul,

Post by Paul Koning

Post by Rainer Orth
Hi Paul,

Post by Paul Koning
Ok, thanks. So adding a dg-skip-if for my target is indeed correct.
Will do so.

please don't: since this is going to be common, please add a
corresponding effective-target keyword instead, together with
sourcebuild.texi documentation. That's far more expressive than
explicit target lists.
Thanks.
Rainer

So you mean, add a new keyword (say, "ieee") to dg-effective-target that
means "run this test only on ieee targets"?

right.

Post by Paul Koning
Another approach might be to have dg-add-options ieee mean what it does
today, but also have it skip the test for non-ieee capable targets. Or is
that undesirable because it muddles the meaning of the dg-add-options
keyword? I figure it would make sense because any test that has
dg-add-options ieee by definition should be skipped by any target that
can't do ieee at all.

No, that's not how things are supposed to work. Look at c99_runtime for
example: we have both
dg-require-effective-target c99_runtime
which checks if the targets supports a C99 runtime, and
dg-add-options c99_runtime
to add special options for targets that need them.
I've no idea why this isn't the case for ieee today.

Probably because we've buried a lot of the ieee specific stuff into
c-torture/{compile,execute}/ieee

jeff

[Joseph Myers]

Post by Paul Koning
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.)

[Paul Koning]

Post by Joseph Myers

Post by Paul Koning
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

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