This is the mail archive of the
mailing list for the binutils project.
Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: <linux-mips at linux-mips dot org>, <libc-alpha at sourceware dot org>, <binutils at sourceware dot org>, <gcc at gcc dot gnu dot org>, Matthew Fortune <Matthew dot Fortune at imgtec dot com>, Daniel Sanders <Daniel dot Sanders at imgtec dot com>, Leonid Yegoshin <Leonid dot Yegoshin at imgtec dot com>
- Date: Fri, 20 Nov 2015 17:16:54 +0000
- Subject: Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 00 dot 1511140411050 dot 7097 at tp dot orcam dot me dot uk> <alpine dot DEB dot 2 dot 10 dot 1511171503510 dot 14808 at digraph dot polyomino dot org dot uk>
On Tue, 17 Nov 2015, Joseph Myers wrote:
> > Any or all of these options may have effects beyond propagating the IEEE
> > Std 754 compliance mode down to the assembler and the linker. In
> > particular `-mieee=strict' is expected to guarantee code generated to
> > fully comply to IEEE Std 754 rather than only as far as NaN representation
> > is concerned.
> "guarantee" seems rather strong given the various known issues with (lack
> of) Annex F support in GCC.
Well, but aren't these current implementation shortcomings (i.e. bugs)
rather than a design principle? I can weaken the language here, but if
the former is the case, then I think we don't need to factor in the
existence of bugs into an interface specification.
> Do you have any actual configuration in mind it would affect,
> MIPS-specific or otherwise? For non-architecture-specific things, -std=
> options for C standards conformance are meant to enable whatever options
> are required (e.g. they disable the default -ffp-contract=fast), without
> affecting things not required by the standards by default (so they don't
> enable -frounding-math or -fsignaling-nans, for example).
The target audience for the `-mieee=strict' option is in my idea a
non-technical user, say a physicist, who does not necessarily know or is
fluent with the guts of computer hardware and who has the need to build
and reliably run their software which uses IEEE Std 754 arithmetic.
Rather than giving such a user necessarily lengthy explanations as to the
complexity of the situation I'd prefer to give them this single option to
guarantee (modulo bugs, as noted above) that a piece of software built
with this option will either produce correct (as in "standard-compliant")
results or refuse to run.
There is also a corresponding `--with-ieee=strict' configure-time option
for users who want to build their own compiler system which guarantees
such compliance by default.
I think the `-std=' options are a little bit too broad in that they
control more than just the IEEE Std 754 aspect of standards compliance.
Of course the setting of `-mieee=' may in fact be a one-way dependency of
`-std=', up to a further override. I haven't implemented such a
dependency in my prototype, however I think it might be a good idea to
What I have implemented is a dependency between `-mieee=' and the
internal option to control the compliance mode for NaN encodings. That
has encountered an unexpected complication though which I was not able to
resolve without turning the option handling machinery upside down, and I
found that code really hard to follow. So I decided to defer it as not
the main scope of the matter and proceed with the rest of the feature.
Once the option handling has been sorted out, a similar dependency can be
introduced between `-std=' and `-mieee='.
I'll post the details of the option handling issue with the GCC patches.
Does this answer address your concerns?