digitalmars.D.bugs - [Issue 365] New: Regression: Bad code generation for floating point == and !=
- d-bugmail puremagic.com (22/23) Sep 24 2006 http://d.puremagic.com/issues/show_bug.cgi?id=365
- Thomas Kuehne (16/26) Sep 29 2006 -----BEGIN PGP SIGNED MESSAGE-----
- Don Clugston (5/38) Sep 29 2006 I just discovered that this is duplicate of BUG 291 (except that this
- d-bugmail puremagic.com (9/9) Oct 02 2006 http://d.puremagic.com/issues/show_bug.cgi?id=365
- d-bugmail puremagic.com (4/4) Oct 04 2006 http://d.puremagic.com/issues/show_bug.cgi?id=365
- Christian Kamm (6/6) Oct 11 2006 After the following assignment
- Walter Bright (2/10) Oct 11 2006 The language doesn't guarantee order of evaluation within an expression.
- J Duncan (2/13) Oct 11 2006 Indeed, and it can drive you crazy in a debugger :)
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 d-bugmail puremagic.com schrieb am 2006-09-24:http://d.puremagic.com/issues/show_bug.cgi?id=365NaNs are currently comparing equal to zero!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-----, >=, !<>=, etc all seem to be OK.------- void main() { real x = real.nan; assert( x!=0 ); // fails if (x==0) assert(0); // fails }
Sep 29 2006
Thomas Kuehne wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 d-bugmail puremagic.com schrieb am 2006-09-24: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.http://d.puremagic.com/issues/show_bug.cgi?id=365NaNs are currently comparing equal to zero!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-----, >=, !<>=, etc all seem to be OK.------- void main() { real x = real.nan; assert( x!=0 ); // fails if (x==0) assert(0); // fails }
Sep 29 2006
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
http://d.puremagic.com/issues/show_bug.cgi?id=365 Fixed DMD 0.168 --
Oct 04 2006
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
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
Walter Bright wrote:Christian Kamm wrote:Indeed, and it can drive you crazy in a debugger :)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