This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Minimum floating-point requirements

Steve, I don't think I've seen any followup to this message 
<>.  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.

Joseph S. Myers

On Thu, 30 Jan 2014, Joseph S. Myers wrote:

> On Thu, 30 Jan 2014, Steve Munroe wrote:
> > Joseph I don't follow GCC closely these days and so am not clear about what
> > you are proposing.
> > 
> > Can you point me to a bugzilla or change log?
> is the libgcc patch in question to avoid spurious internal overflows.  One 
> of the fixes there is needed for cbrtl (LDBL_MAX) to work - but it seemed 
> prudent to fix the whole class of issues rather than keep finding more 
> cropping up as glibc test coverage improves and needing each time to track 
> them back to a particular bug that could have been fixed earlier.
> is the issue for non-default rounding modes (where I suggested possibly 
> having separate __gcc_*_round functions used only with -frounding-math, if 
> the performance cost of saving and restoring the rounding mode is 
> significant).
> In addition to those two, there are various cases of spurious underflow 
> exceptions when the final result of multiplication (probably division as 
> well) is not in the subnormal long double range so should not have that 
> exception.  These cause glibc test failures just as the other issues do.
> I don't object to Mike Stump's suggestion in 
> <> of an option 
> -mieee (which would then be used automatically by the glibc build) to 
> enable all these various fixes together (although since this is inherently 
> not an IEEE floating-point format, the name -mieee seems a little odd - 
> and I had previously been thinking in terms of the generic functions doing 
> everything except allowing for different rounding modes, and wrappers that 
> deal with those, rather than two full variant copies of each function).
> (glibc note: for software floating point, another libc-exported 
> reserved-namespace function would be needed for libgcc to use to change 
> temporarily to round-to-nearest.  I'm minded to call it __feswapround, 
> thinking of __swapround in the example code for the FENV_ROUND pragma in 
> draft TS 18661-1.  This would only be needed for software floating point 
> (and so need to be in e500 glibc for ABI compatibility), since for 
> hardware floating point libgcc could use asms for changing the rounding 
> mode.  Obviously this would now be a matter for 2.20 or later.)
> -- 
> Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]