This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] MIPS: IEEE 754-2008 NaN encoding features
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: <binutils at sourceware dot org>
- Date: Thu, 11 Jul 2013 22:27:56 +0100
- Subject: Re: [PATCH] MIPS: IEEE 754-2008 NaN encoding features
- References: <alpine dot DEB dot 1 dot 10 dot 1212032223130 dot 21659 at tp dot orcam dot me dot uk> <87txrw50et dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1212081235080 dot 21659 at tp dot orcam dot me dot uk> <87ehj04gyq dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1307081309580 dot 20590 at tp dot orcam dot me dot uk> <871u786d7y dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1307082138400 dot 20590 at tp dot orcam dot me dot uk> <87mwps3n73 dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1307112137200 dot 20590 at tp dot orcam dot me dot uk>
"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> On Thu, 11 Jul 2013, Richard Sandiford wrote:
>
>> >> --------------------------------------------------------------------------
>> >> This option indicates whether the source code uses the IEEE 2008
>> >> NaN encoding (@option{-mnan=2008}) or the original MIPS encoding
>> >> (@option{-mnan=legacy}). It is equivalent to adding a @code{.nan}
>> >> directive to the beginning of the source file. @xref{MIPS NaN Encodings}.
>> >>
>> >> @option{-mnan=legacy} is the default if no @option{-mnan} option or
>> >> @code{.nan} directive is used.
>> >> --------------------------------------------------------------------------
>> >
>> > Quite a bit sorter! However the directive does not have to be at the
>> > beginning (the setting cannot be flipped so the last one wins). I have
>> > therefore removed "the beginning of". I have shortened the index entry
>> > too, to follow our usual format.
>>
>> Hmm, but I suggested that because I thought any ".nan" in the source
>> code would override the command-line option.
>
> Yes, ".nan" overrides the corresponding command-line options (any number
> of them), however it does not operate like ".set foo" does, only taking
> effect from its location on. As the last ".nan" setting ultimately wins,
> the description could say:
>
> "It is equivalent to adding a @code{.nan} directive to the end of the
> source file."
>
> and would still be accurate.
If it effectively came at the end then the command-line option would
take precedence over any ".nan" directives in the source file. If it
effectively came at the beginning then the final ".nan" directive in the
source file would take precedence over the command-line option. The latter
is what happens. And the main section explicitly says that the last ".nan"
directive wins.
We use the same wording elsewhere, so I hadn't realised this would
be so controversial. Naybe I should have stuck to my guns about
making it an error when the command-line option and directive are
both used but contradict one another.
How about:
+This option indicates whether the source code uses the IEEE 2008
+NaN encoding (@option{-mnan=2008}) or the original MIPS encoding
+(@option{-mnan=legacy}). It only has an effect when the source
+file contains no @code{.nan} directive. @xref{MIPS NaN Encodings}.
+
+@option{-mnan=legacy} is the default if no @option{-mnan} option or
+@code{.nan} directive is used.
instead?
Richard