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: FP comparisons, C, X86, and NaN's


On Sun, 20 Jun 2004, Chris Lattner wrote:

| On 18 Jun 2004, Gabriel Dos Reis wrote:
|
| >
| > | > > 2. C does not define whether or not standard relational operations trap.
| > | > >    If this is the case, there is no bug in GCC.
| >
| > | So you are saying that this is the case: it is undefined whether an
| > | implementation traps on a comparison with nans?  This is my interpretation
| > | of this passage:
| >
| > No!  That section explicitly says that isxxx type generic macros
| > are _quiet_ in the sense that they *do not raise* floating-point
| > exception or traps or whatever.  It is not implementation defined.  It
| > is prescribed.  Please consider the whole section I quoted.
|
| I'm sorry, I meant standard relational operators like < and >.  The
| behavior of the isxxx macros are quite clear.

OK, there was a misunderstanding then.  sorry.

|  Is it undefined whether or
| not the <,> operators trap? (I'm guessing no from your later response)

If you have the pragma FENV_ACCESS on, then those operators will raise a
floating-point exception on NaNs.  Otherwise, it is unspecified.
So, if you put if off, it does not mean the operation will not raise
a floating-point exception.  It just means it _may_ or _may not_.


| > | >         --   is  true.   Relational   operators   may   raise   the
| > | >        ``invalid''  floating-point  exception  when argument values
| > | >        are NaNs.
| > |
| > | I just want to make sure that I'm intepreting things correctly.
| >
| > "Relation operators" in the above quote means the usual <, >, <=, >=,
| > ==, !=.  Not the isgreater, isxxxx... type generic macros.
| >
| > Said differently, you've discovered a bug in the code GCC generates.
|
| From this, I take it to mean that < is defined to trap if either operand
| is a QNaN or SNaN.  Is this what you mean?

Yes, that is what I meant -- provided you set FENV_ACCESS on.

Unfortunately, the C99 standard leaves implementation-defined what the
default state should be.

What is the default state for the intel compiler?

Sorry not having been precise enough.


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