[RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking

[Joseph Myers]

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
joseph@codesourcery.com