This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] MIPS: IEEE 754-2008 NaN encoding features
"Maciej W. Rozycki" <email@example.com> writes:
> On Sat, 8 Dec 2012, Richard Sandiford wrote:
>> > As many of you have been aware it has been a long practice for software
>> > using IEEE 754 floating-point arithmetic run on MIPS processors to use an
>> > encoding of Not-a-Number (NaN) data different to one used by software run
>> > on other processors. And as of IEEE 754-2008 revision this encoding does
>> > not follow one recommended in the standard, as specified in section 6.2.1,
>> > where it is stated that quiet NaNs should have the first bit (d1) of their
>> > significand set to 1 while signalling NaNs should have that bit set to 0,
>> > but MIPS software interprets the two bits in the opposite manner.
>> > An upcoming MIPS Architecture revision will provide for processors that
>> > support the IEEE 754-2008 preferred NaN encoding format. As the two
>> > formats (further referred to as "legacy NaN" and "2008 NaN") are
>> > incompatible to each other, tools will have to provide support for the two
>> > formats to help people avoid using incompatible binary modules. Here is
>> > the binutils part.
>> > Two new entities have been added to support static and dynamic linking.
>> > For the former a set of new ELF file attribute values have been defined.
>> > For the latter a new ELF file header flag has been defined. These changes
>> > are described in detail below.
>> But an ELF flag supports static and dynamic linking on its own.
>> Encoding the same information in the attribute seems redundant,
>> and makes the implementation a fair bit more complicated.
> Sources need to be annotated as NaN encodings will be present within them
> -- .gnu_attribute is suited for this purpose. The header flag is required
> so that the kernel configures the FPU appropriately or rejects binaries
> that are incompatible with hardware being used that does not support the
> NaN encoding requested and also so that ld.so refuses to load incompatible
> modules together.
> Do you have any better proposal? I can drop the setting on the header
> flag on relocatables and keep it on final binaries only if that made you
> feel better.
Well, I don't agree the source _needs_ to be annotated with the NaN encoding.
The annotation is as easy to forget as the command-line option. However,
I realise that's a bit of a religious debate, and that others think that:
gcc -c foo.c -mfoo -mblah -mfrob
ought to be equivalent to:
gcc -S foo.c -mfoo -mblah -mfrob
Although it doesn't seem that important to me, I've no objection if
there's a concerted attempt to move in that direction. The approach
taken in the patch is different though. When the source sets an IEEE
NaN FP attribute, the patch also requires -mnan2008 to be passed on
the command line and reports an error if the user forgets.
If we require -mnan2008 to be passed anyway, then all the source
annotation does is provide a bit of extra error checking. I'm not
convinced that that check is worth all the extra complexity. The
file-level PIC, ABI and architecture header flags are all set from
similar, unchecked, options, and I'm not aware that passing the wrong
options is a common source of error. Either way, the consistency
check should be contained within the assembler, whereas using
".gnu_attribute" for the source annotation requires an underlying
attribute flag that must at all times mirror the header flag.
If instead we want to support source annotation without command-line options
the "as foo.s" stance above), and command-line options without source
annotation (e.g. for assembler source that doesn't use FP), then how about
having a command-line option:
and a directive:
Both would act in the same way and it would be an error to contradict
a previous setting. (I wondered about ".set nan..." instead of ".nan",
but this doesn't really work like other .set options, and shouldn't for
example be used in a push/pop sequence.) Of course, if neither are used,
we assume legacy.