This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: dg-add-options ieee ?
- From: Jeff Law <law at redhat dot com>
- To: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>, Paul Koning <paulkoning at comcast dot net>
- Cc: Segher Boessenkool <segher at kernel dot crashing dot org>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 2 Nov 2018 19:38:50 -0600
- Subject: Re: dg-add-options ieee ?
- References: <ECFA11AD-AF3F-4B2F-842F-050E00FB3B3B@comcast.net> <20181031195551.GH5994@gate.crashing.org> <172440D0-3284-442D-97C4-88AA25B39B56@comcast.net> <yddd0rpkhak.fsf@CeBiTec.Uni-Bielefeld.DE> <0032353A-4615-476B-B05F-00348FB450FB@comcast.net> <ydd8t2dkdrq.fsf@CeBiTec.Uni-Bielefeld.DE>
On 10/31/18 3:27 PM, Rainer Orth wrote:
> Hi Paul,
>
>>> On Oct 31, 2018, at 4:11 PM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> 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