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
Don Clugston <dac nospam.com.au> 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