digitalmars.D.bugs - [Issue 365] New: Regression: Bad code generation for floating point == and !=
- d-bugmail puremagic.com Sep 24 2006
- Thomas Kuehne <thomas-dloop kuehne.cn> Sep 29 2006
- Don Clugston <dac nospam.com.au> Sep 29 2006
- d-bugmail puremagic.com Oct 02 2006
- d-bugmail puremagic.com Oct 04 2006
- "Christian Kamm" <kamm incasoftware.de> Oct 11 2006
- Walter Bright <newshound digitalmars.com> Oct 11 2006
- J Duncan <jtd514 nospam.ameritech.net> Oct 11 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 } --
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=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
Don Clugston <dac nospam.com.au> 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
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 *** --
Oct 02 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 --
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: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