Minimum floating-point requirements

[Joseph S. Myers]

On Sat, 8 Feb 2014, David Edelsohn wrote:

> On Fri, Feb 7, 2014 at 6:51 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> > Steve, I don't think I've seen any followup to this message
> > <https://sourceware.org/ml/libc-alpha/2014-01/msg00714.html>.  As I note
> > there, I'd be happy with Mike Stump's suggestion of a -mieee option (with
> > whatever name the powerpc GCC maintainers might prefer) enabling use of
> > new libgcc functions __gcc_qadd_ieee, __gcc_qsub_ieee, __gcc_qmul_ieee,
> > __gcc_qdiv_ieee, where would have more careful treatment of exceptions
> > (and in future of rounding modes) than the main _gcc_* functions.
> 
> Which mode are you and Mike proposing as the default?  Based on the
> proposed naming, I assume that the current behavior will remain with
> the current names of the functions. I assume that -mieee (or whatever
> command line option is chosen) will not be the default?

I am not proposing changing the default - that is, -mieee would not be the 
default.

There are the two separate issues of exceptions and rounding modes, and in 
principle a user could want only stricter exception handling while not 
using modes other than round-to-nearest, or only rounding mode handling 
without caring about exceptions.  However, I'm only proposing one set of 
new functions rather than two or three; for glibc, both rounding mode 
handling and stricter exception handling are wanted together.  (This does 
raise the question of whether -frounding-math should also enable using the 
*_ieee functions, as the only way to get valid results in non-default 
rounding modes.)

> How do you propose this interact with, for example, libstdc++? A
> multilib will be odious, but one will not obtain full conformance if
> one mixes code that references both sets of symbols.

I'm not proposing changes to libstdc++.

For functions implemented through templates in headers, the options used 
by the library user will determine which functions are used.  For 
functions in the prebuilt library, I think the same reasoning as for glibc 
indicates that libstdc++ should be built with the new option (or 
-frounding-math): C++11 includes <cfenv> which allows changing rounding 
modes, and without anything in the standard to restrict what functions or 
operations may be used in non-default rounding modes, all functions and 
operations must follow their specified semantics when used in such modes - 
meaning, in particular, that the results of long double functions and 
operations need to be valid long double values.  (This is different from 
floating-point configurations that can only be achieved by direct register 
manipulation, or from signal handlers where the standards have explicit 
restrictions on what interfaces may be used.)  So in the absence of 
separate versions of libstdc++ functions for use with -frounding-math, 
that indicates building libstdc++ to use the new functions.  However, I 
propose to leave any such changes to the libstdc++ maintainers.

-- 
Joseph S. Myers
joseph@codesourcery.com