dg-add-options ieee ?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

dg-add-options ieee ?

Paul Koning-6
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

Reply | Threaded
Open this post in threaded view
|

Re: dg-add-options ieee ?

Segher Boessenkool
On Wed, Oct 31, 2018 at 02:20:38PM -0400, Paul Koning wrote:
> 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).

> 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
Reply | Threaded
Open this post in threaded view
|

Re: dg-add-options ieee ?

Paul Koning-6


> On Oct 31, 2018, at 3:55 PM, Segher Boessenkool <[hidden email]> wrote:
>
> On Wed, Oct 31, 2018 at 02:20:38PM -0400, Paul Koning wrote:
>> 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.
>
> ...
>
> 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).
>
>> ...
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: dg-add-options ieee ?

Rainer Orth-2
Hi Paul,

> 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

--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
Reply | Threaded
Open this post in threaded view
|

Re: dg-add-options ieee ?

Paul Koning-6


> On Oct 31, 2018, at 4:11 PM, Rainer Orth <[hidden email]> wrote:
>
> Hi Paul,
>
>> 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


Reply | Threaded
Open this post in threaded view
|

Re: dg-add-options ieee ?

Rainer Orth-2
Hi Paul,

>> On Oct 31, 2018, at 4:11 PM, Rainer Orth <[hidden email]> wrote:
>>
>> Hi Paul,
>>
>>> 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.

> 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

--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
Reply | Threaded
Open this post in threaded view
|

Re: dg-add-options ieee ?

Joseph Myers
In reply to this post by Paul Koning-6
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: dg-add-options ieee ?

Paul Koning-6


> On Oct 31, 2018, at 5:47 PM, Joseph Myers <[hidden email]> 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
> [hidden email]

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

Reply | Threaded
Open this post in threaded view
|

Re: dg-add-options ieee ?

Jeff Law
In reply to this post by Rainer Orth-2
On 10/31/18 3:27 PM, Rainer Orth wrote:

> Hi Paul,
>
>>> On Oct 31, 2018, at 4:11 PM, Rainer Orth <[hidden email]> wrote:
>>>
>>> Hi Paul,
>>>
>>>> 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.
>
>> 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