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@xxxxxxxxxxxxxxxx
