Thread overview
[Issue 365] New: Regression: Bad code generation for floating point == and !=
Sep 24, 2006
d-bugmail
Sep 29, 2006
Thomas Kuehne
Sep 29, 2006
Don Clugston
Oct 02, 2006
d-bugmail
Oct 05, 2006
d-bugmail
side effect on assignment to associative array
Oct 11, 2006
Christian Kamm
Oct 11, 2006
Walter Bright
Oct 11, 2006
J Duncan
September 24, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=365

           Summary: Regression: Bad code generation for floating point ==
                    and !=
           Product: D
           Version: 0.167
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: critical
          Priority: P1
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: clugdbug@yahoo.com.au


NaNs are currently comparing equal to zero!
>, >=, !<>=, etc all seem to be OK.
-------
void main()
{
    real x = real.nan;
    assert( x!=0 );              // fails
    if (x==0) assert(0);         // fails
}


-- 

September 29, 2006
d-bugmail@puremagic.com schrieb am 2006-09-24:
> http://d.puremagic.com/issues/show_bug.cgi?id=365

> NaNs are currently comparing equal to zero!
>>, >=, !<>=, etc all seem to be OK.
> -------
> void main()
> {
>     real x = real.nan;
>     assert( x!=0 );              // fails
>     if (x==0) assert(0);         // fails
> }

Added to DStress as http://dstress.kuehne.cn/compile/o/opEquals_06_A.d http://dstress.kuehne.cn/compile/o/opEquals_06_B.d http://dstress.kuehne.cn/compile/o/opEquals_06_C.d http://dstress.kuehne.cn/run/o/opEquals_06_D.d http://dstress.kuehne.cn/run/o/opEquals_06_E.d http://dstress.kuehne.cn/run/o/opEquals_06_F.d

Thomas


September 29, 2006
Thomas Kuehne wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> d-bugmail@puremagic.com schrieb am 2006-09-24:
>> http://d.puremagic.com/issues/show_bug.cgi?id=365
> 
>> NaNs are currently comparing equal to zero!
>>> , >=, !<>=, etc all seem to be OK.
>> -------
>> void main()
>> {
>>     real x = real.nan;
>>     assert( x!=0 );              // fails
>>     if (x==0) assert(0);         // fails
>> }
> 
> Added to DStress as
> http://dstress.kuehne.cn/compile/o/opEquals_06_A.d
> http://dstress.kuehne.cn/compile/o/opEquals_06_B.d
> http://dstress.kuehne.cn/compile/o/opEquals_06_C.d
> http://dstress.kuehne.cn/run/o/opEquals_06_D.d
> http://dstress.kuehne.cn/run/o/opEquals_06_E.d
> http://dstress.kuehne.cn/run/o/opEquals_06_F.d
> 
> Thomas
> 
> 
> -----BEGIN PGP SIGNATURE-----
> 
> iD8DBQFFHOLcLK5blCcjpWoRAjU4AJ9V52QPfPZ6S9y27DuqBxKjv1IvVQCfS6hJ
> UVgj8nqZ50tE0Q3TBBJTn4Y=
> =iS3i
> -----END PGP SIGNATURE-----

I just discovered that this is duplicate of BUG 291 (except that this bug report includes != ). However, I really think this is a critical error -- it's caused severe problems in some of my mathematical code, where I make significant use of NaNs.
October 02, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=365


thomas-dloop@kuehne.cn changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




------- Comment #3 from thomas-dloop@kuehne.cn  2006-10-02 03:11 -------


*** This bug has been marked as a duplicate of 291 ***


-- 

October 05, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=365





------- Comment #4 from bugzilla@digitalmars.com  2006-10-04 19:59 -------
Fixed DMD 0.168


-- 

October 11, 2006
After the following assignment

int[int] aa;
aa[0] = aa.length;

aa[0] does contain 1. I would have expected the right hand side to be evaluated first, thus resulting in 0 being assigned to aa[0]. Is this intended behaviour or a bug?
October 11, 2006
Christian Kamm wrote:
> After the following assignment
> 
> int[int] aa;
> aa[0] = aa.length;
> 
> aa[0] does contain 1. I would have expected the right hand side to be evaluated first, thus resulting in 0 being assigned to aa[0]. Is this intended behaviour or a bug?

The language doesn't guarantee order of evaluation within an expression.
October 11, 2006
Walter Bright wrote:
> Christian Kamm wrote:
>> After the following assignment
>>
>> int[int] aa;
>> aa[0] = aa.length;
>>
>> aa[0] does contain 1. I would have expected the right hand side to be evaluated first, thus resulting in 0 being assigned to aa[0]. Is this intended behaviour or a bug?
> 
> The language doesn't guarantee order of evaluation within an expression.

Indeed, and it can drive you crazy in a debugger :)