This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: [RFC, MIPS] Relax NaN rules


On Fri, 21 Mar 2014, Rich Fuhler wrote:

> Hi Joseph, as I remember from conversations last year, there is also an 
> issue if the programmer specifically enables the FPU exceptions. If the 
> FPU, kernel emulator, or bare-metal emulator (CS3's for example) did 
> raise a signaling NaN, then the intermixing couldn't be done. As I 
> remembering this correctly?

I'm not clear on what the question is.  But if, say, a program uses only 
quiet NaNs, and cares about the "invalid" exception, but gets used on 
wrongly configured hardware or with libraries with an inconsistent notion 
of what a quiet NaN is, then it may get spurious "invalid" exceptions from 
some of the other pieces thinking they've received a signaling NaN.

> I ask this for another reason as well: since we're adding IFUNC 
> capability to MIPS, we may need to harden the dynamic loader to protect 
> $f12 and $f14. If signaling NaN was raised on the load, then we have 
> more problems to deal with...

I haven't looked at the details of what MIPS hardware does with signaling 
NaN loads - but in general uses of signaling NaNs work better if loads 
don't trigger the NaN, only arithmetic, conversions and other operations 
that IEEE 754 specifies should trigger it, so loads and stores always 
preserve the original bit-patterns.  (Cf. the bugs on x86 where a union 
gets copied via its double member, even though some other member is 
active, and so gets corrupted because the signaling NaN gets converted to 
quiet along the way.)

-- 
Joseph S. Myers
joseph@codesourcery.com


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