not-a-number's

[Mischa Baars]

On 01/16/2013 02:53 PM, Richard Biener wrote:
> On Wed, Jan 16, 2013 at 1:52 PM, Mischa Baars <mjbaars1977@gmail.com> wrote:
>> On 01/16/2013 01:28 PM, Robert Dewar wrote:
>>> On 1/16/2013 7:10 AM, Mischa Baars wrote:
>>>
>>>> And as I have said before: if you are satisfied with the answer '2',
>>>> then so be it and you keep the compiler the way it is, personally I'm am
>>>> not able to accept changes to the sources anyway. I don't think it is
>>>> the right answer though.
>>>
>>> The fact that you don't think that gcc shoudl follow the C standard
>>> is hardly convincing unless it is backed up by convincing technical
>>> argument. I see nothing surprising about the 2 here, indeed any other
>>> answer *would* be surprising. I still don't understand the basis for
>>> your non-stnadard views.
>>>>
>>>> Mischa.
>>>>
>> 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.
>>
>> Does that make sense to you?
>>
>> In our example, a 'not-a-number' would be returned to the main program,
>> without the need for an extra 'isnan()'.
> You can enable FP exceptions via fpsetexceptflag and friends (it's disabled
> in the FPU by default) and if you then make sure to compile with
> -fsignalling-nans (that's not the default) you will get the desired behavior
> (program termination via an exception).
>
> Richard.

Yes, I understand that more or less the same can be done with signaling 
not-a-numbers. By unmasking the appropriate bits in the exception mask, 
indeed the 'invalid operation' exception would be triggered on the first 
'if' statement. Probably the whole program including the 'main()' loop 
is terminated that way, but I have never looked at the actual handler 
more close, so I can't with certainty.
Also this was not what I intended to do, I was trying to work with quiet 
not-a-numbers explicitly to avoid the 'invalid operation' exception to 
be triggered, so that my program can work it's way through the 
calculations without being terminated by the intervention of a signal 
handler. When any not-a-number shows up in results after execution, then 
you know something went wrong. When the program does what it is supposed 
to do, you could remove any remaining debug code, such as the boundary 
check in the trigonometric functions.

Mischa.