On 2017-05-14 00:43:52 +0800, Liu Hao wrote: > On 2017/5/13 23:58, Vincent Lefevre wrote: > > On 2017-05-13 11:06:06 +0800, Liu Hao wrote: > > > On 2017/5/13 10:25, Vincent Lefevre wrote: > > > > On 2017-05-12 23:46:09 +0800, Liu Hao wrote: > > > > But if you do this, you're out of scope of the standards. > > > > > > > > Moreover, I suppose that you will also get a floating-point exception > > > > on a signaling NaN, in which case, on this example, this isn't > > > > distinguishable from a signaling NaN. > > ^^^^^^^^^ > > > A QNaN doesn't generate an exception regardless of the x87 control word. > > > > It isn't because the value doesn't generate a trap. FP exceptions > > are a different notion. They are generated by operations, not by > > reading values. > Reading NaNs (regardless of signaling-ness) or invalid values doesn't raise > exceptions. However: > > (This is a rough conclusion from Intel manuals and any disagreement is > unintentional. Please check Intel manuals for sure.) Well, there are different points of views. One is what the processor delivers. Another one is what one should see from a conforming IEEE 754 implementation, for instance with C + long double in the cases where long double is regarded as an extended format. > 0) If an arithmetic operation is performed on a QNaN, the result is a > QNaN, no exception is raised. (This out of scope in this topic.) > 1) If an arithmetic operation is performed on a SNaN, an #IA exception > is raised (regardless of whether it is masked or not, similarly > hereinafter). > 2) If the `FST` or `FSTP` instruction is used to store a SNaN to a > memory location and that location is not a `TBYTE` (ten bytes), an > #IA exception is raised. The SNaN is copied as-is when stored as > the 80-bit extended precision format without any exceptions raised. > 3) If an arithmetic operation is performed on an invalid operand, the > same happens with 1). > 4) If the `FST` or `FSTP` instruction is used to store an invalid > operand to a memory location, an #IA exception is raised regardless > of size of that location. > > Since case 2) and 4) differ, a SNaN and an invalid operand are *not* > indistinguishable. Well, perhaps at the processor level. But in IEEE 754... The notion of "invalid operand" in 6.1 is used and refers to 7.2 about invalid operation. Basically, this is 3). So, the issue seems to be specific to the FST and FSTP instructions. But these instructions do not correspond to anything in IEEE 754. This means that if a compiler wants to use them, then it should make sure that the so-called "invalid operands" behave like SNaN. Note that for a copy, negate and abs, no exceptions should be raised in such a case. These are "quiet-computational operations" (Section 5.5.1 "Sign bit operations" in IEEE 754-2008). In C, an assignment with no type conversion corresponds to a "copy" or equivalently nothing, the unary minus is "negate", and fabs is "abs" (Annex F of the C standard). If you get an exception, then this is a compiler bug. > > > Let's try `=` which corresponds to the IEEE 754 equality operator too: > > > > No, in C, '=' is an assignment operator. > Good catch, and apparently it was an oversight. I meant to say > 'assignment operator'. So, this corresponds to "copy" in IEEE 754-2008. > > But they might also see this as undefined behavior, in which case > > long double mustn't be documented as being the x86 double-extended > > format. > > > ISO C permits implementations to define additional macro constants for the > `fpclassify` macro that match the regexp `FP_[A-Z][A-Za-z0-9_]*`. The only > problem we have at the moment is that we don't have a constant for invalid > operands. ISO C, but not IEEE 754. So, in this case, this would no longer be an IEEE format. GCC currently documents long double as being "IEEE extended-precision" on x86. It just needs to be consistent. -- Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
