This is the mail archive of the
mailing list for the GCC project.
Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Maciej W. Rozycki" <macro at imgtec 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 18:25:42 +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> <alpine dot DEB dot 2 dot 00 dot 1511201535580 dot 6915 at tp dot orcam dot me dot uk>
On Fri, 20 Nov 2015, Maciej W. Rozycki wrote:
> 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.
This does not make any sense. The correspondence between IEEE 754
operations and source code in C or other languages is extremely
complicated. If the user thinks of C as some form of portable assembler
for IEEE 754 operations, that is not something effectively supportable.
Can we assume that if the user depends on rounding modes, they will use
the FENV_ACCESS pragma (not implemented, of course) or -frounding-math?
Can we assume that their dependence on the absence of contraction of
expressions is in accordance with ISO C rules (again, FP_CONTRACT isn't
implemented but -ffp-contract=off is)? Can we assume that they don't
depend on signaling NaNs? Can we assume they don't depend on trap
handlers that count the number of times a given exception occurs, since
that is explicitly unsupported by ISO C?
An option like that has to be defined in terms of existing C bindings for
IEEE 754, not in terms of supporting users who don't know what they are
doing and are unfamiliar with how C source code constructs are mapped to
IEEE 754 operations and what features the C standard allows non-default
pragmas or options to be required for.
> Does this answer address your concerns?
No, the option concept as described seems too irremediably vague.
Joseph S. Myers