www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 365] New: Regression: Bad code generation for floating point == and !=

reply d-bugmail puremagic.com writes:
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 } --
Sep 24 2006
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----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-----
Sep 29 2006
parent Don Clugston <dac nospam.com.au> writes:
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.
Sep 29 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=365


thomas-dloop kuehne.cn changed:

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







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


-- 
Oct 02 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=365






Fixed DMD 0.168


-- 
Oct 04 2006
prev sibling parent reply "Christian Kamm" <kamm incasoftware.de> writes:
After the following assignment

int[int] aa;
aa[0] =3D 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?
Oct 11 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Oct 11 2006
parent J Duncan <jtd514 nospam.ameritech.net> writes:
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 :)
Oct 11 2006