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: not-a-number's


On Wed, Jan 16, 2013 at 4:52 AM, Mischa Baars <mjbaars1977@gmail.com> wrote:
>
> Let me explain again for you. Every 'if' statement in C is translated into a
> 'fucom' or similar instruction, which sets a number of conditions flags in
> the co-processor. Some instructions need you to load these into the eflags
> register manually, others don't.
>
> Now, as soon as the 'fucom' or similar instruction encounters a 'signalling
> not-a-number' or 'quiet not-a-number' as one or both of it's arguments, the
> condition code is set to 'not comparable'. This has nothing to do with the C
> specification, but purely with the Intel/AMD hardware.
>
> If you ask me, it would be counter-intuitive to change the value of the
> condition code to some other value and call that the new standard. Instead
> it would seem logical to use the 'not comparable' and terminate the 'if'
> statement.

You appear to be confusing the details of processor implementation
with the C language.  The C language is defined by a language
standard, not by processor implementations.  The language standard
defines how NaN values should behave on systems that use them.

If you want a C program to act in some other way, you need to describe
that change in terms of the C language, not in terms of a processor
implementation.  For example, you could say "if any function does a
comparison of floating point values, and one of the floating point
values is a NaN, then the function should return immediately.  The
return value should be ...."  You are going to have to finish that
sentence, because I have no idea what you intend.

Ian


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