On 01/17/2013 04:46 PM, Vincent Lefevre wrote:
On 2013-01-17 16:33:56 +0100, Mischa Baars wrote:
Actually it is the correct way, as long as you stick to the
conventions. A QNaN is not supposed to change into anything, also
not with the pow(). Only the other way around. Normal numbers can
change
On 2013-01-17 16:33:56 +0100, Mischa Baars wrote:
> Actually it is the correct way, as long as you stick to the
> conventions. A QNaN is not supposed to change into anything, also
> not with the pow(). Only the other way around. Normal numbers can
> change into QNaN's.
The C standard specified pow
On 01/17/2013 04:33 PM, Mischa Baars wrote:
On 01/17/2013 01:08 PM, Gabriel Paubert wrote:
On Thu, Jan 17, 2013 at 12:21:04PM +0100, Vincent Lefevre wrote:
On 2013-01-17 06:53:45 +0100, Mischa Baars wrote:
Also this was not what I intended to do, I was trying to work with
quiet
not-a-numbers e
On 2013-01-17 15:01:20 +0100, Andreas Schwab wrote:
> Andreas Schwab writes:
> > The C standard does not place any requirement on < wrt. exceptions or
> > lack thereof.
Agreed, this is a "may" (7.12.14), but...
> But IEC 559 does, of course.
and in particular, if __STDC_IEC_559__ is defined, th
On 01/17/2013 01:08 PM, Gabriel Paubert wrote:
On Thu, Jan 17, 2013 at 12:21:04PM +0100, Vincent Lefevre wrote:
On 2013-01-17 06:53:45 +0100, Mischa Baars wrote:
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' ex
Andreas Schwab writes:
> The C standard does not place any requirement on < wrt. exceptions or
> lack thereof.
But IEC 559 does, of course.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something com
Gabriel Paubert writes:
> Hmm, are you sure that this part is properly implemented in gcc, using
> unordered compare versus ordered compare instructions depending on
> the operator you use?
For quiet compare operations you need to use isgreater etc.
> At least on PPC, floating point compares a
On 2013-01-17 13:08:17 +0100, Gabriel Paubert wrote:
> Hmm, are you sure that this part is properly implemented in gcc, using
> unordered compare versus ordered compare instructions depending on
> the operator you use?
>
> At least on PPC, floating point compares always use the unordered
> instr
On Thu, Jan 17, 2013 at 12:21:04PM +0100, Vincent Lefevre wrote:
> On 2013-01-17 06:53:45 +0100, Mischa Baars wrote:
> > 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 p
On 2013-01-17 06:57:12 +0100, Mischa Baars wrote:
> >What exactly do you mean by "terminate the if"?? Do you mean skip the
> >whole compound statement, including any "else" clause?
> Yes, exactly. Skip it, including the 'else'.
This is not how C works. Perhaps instead of
if (x < y)
...
e
On 2013-01-17 06:53:45 +0100, Mischa Baars wrote:
> 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 termina
On 01/16/2013 07:23 PM, David Paterson wrote:
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
Of Mischa Baars
Sent: 16 January 2013 12:53
To: Robert Dewar; gcc@gcc.gnu.org
Subject: Re: not-a-number's
On 01/16/2013 01:28 PM, Robert Dewar wrote
On 01/16/2013 02:53 PM, Richard Biener wrote:
On Wed, Jan 16, 2013 at 1:52 PM, Mischa Baars 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 compile
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
> Of Mischa Baars
> Sent: 16 January 2013 12:53
> To: Robert Dewar; gcc@gcc.gnu.org
> Subject: Re: not-a-number's
>
> On 01/16/2013 01:28 PM, Robert Dewar wrote:
>
On 2013-01-16 14:53:42 +0100, Richard Biener wrote:
> 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
On Wed, Jan 16, 2013 at 4:52 AM, Mischa Baars 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
On 2013-01-16 12:47:46 +0100, Mischa Baars wrote:
> On 01/16/2013 12:07 PM, Andrew Haley wrote:
> >Comparisons with NaN don't terminate a statement, and they don't
> >return a NaN. They return a boolean.
> They shouldn't return anything, the comparison should be terminated.
This depends on the co
Richard Biener writes:
> 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).
That wi
On 1/16/2013 5:00 AM, Andrew Haley wrote:
On 01/16/2013 11:54 AM, Mischa Baars wrote:
Here's what Standard C, F.8.3 Relational operators, says:
x != x → false The statement x != x is true if x is a NaN.
x == x → true The statement x == x is false if x is a
On Wed, Jan 16, 2013 at 1:52 PM, Mischa Baars 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 a
On 01/16/2013 11:54 AM, Mischa Baars wrote:
>> Here's what Standard C, F.8.3 Relational operators, says:
>> >
>> > x != x → false The statement x != x is true if x is a NaN.
>> >
>> > x == x → true The statement x == x is false if x is a NaN.
>
> And indeed apparently
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
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 y
On 01/16/2013 01:04 PM, Robert Dewar wrote:
On 1/16/2013 6:54 AM, Mischa Baars wrote:
]
And indeed apparently the answer then is '2'. However, I don't think
this is correct. If that means that there is an error in the C
specification, then there probably is an error in the specification.
The C
On 1/16/2013 6:54 AM, Mischa Baars wrote:
]
And indeed apparently the answer then is '2'. However, I don't think
this is correct. If that means that there is an error in the C
specification, then there probably is an error in the specification.
The C specification seems perfectly reasonable to
On 01/16/2013 12:07 PM, Andrew Haley wrote:
On 01/16/2013 09:27 AM, Mischa Baars wrote:
On 01/16/2013 10:06 AM, Andreas Schwab wrote:
Mischa Baars writes:
This means that the first 'if' statement should have been terminated when
There is no such thing as a "terminated statement". The first
On 01/16/2013 12:07 PM, Andrew Haley wrote:
On 01/16/2013 09:27 AM, Mischa Baars wrote:
On 01/16/2013 10:06 AM, Andreas Schwab wrote:
Mischa Baars writes:
This means that the first 'if' statement should have been terminated when
There is no such thing as a "terminated statement". The first
On 01/16/2013 09:27 AM, Mischa Baars wrote:
> On 01/16/2013 10:06 AM, Andreas Schwab wrote:
>> Mischa Baars writes:
>>
>>> This means that the first 'if' statement should have been terminated when
>> There is no such thing as a "terminated statement". The first condition
>> evaluates to true.
> W
On 01/16/2013 10:06 AM, Andreas Schwab wrote:
Mischa Baars writes:
This means that the first 'if' statement should have been terminated when
There is no such thing as a "terminated statement". The first condition
evaluates to true.
Whatever you want, although personally I think it is very un
On 16 January 2013 08:59, Mischa Baars wrote:
> On 01/16/2013 08:57 AM, Eric Botcazou wrote:
>>>
>>> Well, I have an Intel manual here that states that any operation on a
>>> QNaN should return a QNaN, which means that also the compare should
>>> return a QNaN when one or both of the arguments is a
Mischa Baars writes:
> This means that the first 'if' statement should have been terminated when
There is no such thing as a "terminated statement". The first condition
evaluates to true.
> Furthermore, the manual states that any operation on a QNaN should return
> a QNaN.
That is only true f
On 01/16/2013 08:57 AM, Eric Botcazou wrote:
Well, I have an Intel manual here that states that any operation on a
QNaN should return a QNaN, which means that also the compare should
return a QNaN when one or both of the arguments is a QNaN.
No, that isn't how comparisons work. The correct resu
On 01/16/2013 09:14 AM, Andreas Schwab wrote:
Mischa Baars writes:
Furthermore, since 'fxam' will return a 'non-comparable' during the first
compare, I suppose the function should then enter the first 'else' and
return a '4'.
Non-comparable means that NaN != NaN is always true.
Andreas.
So
Mischa Baars writes:
> Furthermore, since 'fxam' will return a 'non-comparable' during the first
> compare, I suppose the function should then enter the first 'else' and
> return a '4'.
Non-comparable means that NaN != NaN is always true.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
> Well, I have an Intel manual here that states that any operation on a
> QNaN should return a QNaN, which means that also the compare should
> return a QNaN when one or both of the arguments is a QNaN.
No, that isn't how comparisons work. The correct result is 2 according to the
comparison rule
On 01/15/2013 05:24 PM, Eric Botcazou wrote:
When disregarding the 'isnan()', the function is returning a '2' when
one or both the arguments is a NaN. Do you suppose this is correct?
If you ask me, it should exit on the first compare and thus return a
not-a-number.
You cannot "exit" a compariso
On 01/15/2013 05:24 PM, Eric Botcazou wrote:
When disregarding the 'isnan()', the function is returning a '2' when
one or both the arguments is a NaN. Do you suppose this is correct?
If you ask me, it should exit on the first compare and thus return a
not-a-number.
You cannot "exit" a compariso
> When disregarding the 'isnan()', the function is returning a '2' when
> one or both the arguments is a NaN. Do you suppose this is correct?
>
> If you ask me, it should exit on the first compare and thus return a
> not-a-number.
You cannot "exit" a comparison in C, one of the branches is always
38 matches
Mail list logo
