[Issue 3918] Parameter use before its use in an AndAnd expression with reals treats NaN as false
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Mon Aug 2 00:12:12 PDT 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3918
--- Comment #3 from Don <clugdbug at yahoo.com.au> 2010-08-02 00:12:09 PDT ---
I investigated this bug because I thought it might be related to the more
difficult bug 4443. Unfortunately, they are unrelated.
This one happens because the variable 'u' is recognised as a common sub
expression (CSE).
Then in cod3.c, jmpopcode(), around line 805, we see this code. The two lines
marked with * mean that it just does a JNE, instead of a JNE/JP combination.
When there's no CSE, the next return is used, "return XP|JNE", which adds the
JP in.
op = e->Eoper;
* if (e->Ecount != e->Ecomsub) // comsubs just get Z bit set
* return JNE;
if (!OTrel(op)) // not relational operator
{
tym_t tymx = tybasic(e->Ety);
if (tyfloating(tymx) && config.inline8087 &&
(tymx == TYldouble || tymx == TYildouble || tymx == TYcldouble ||
tymx == TYcdouble || tymx == TYcfloat ||
op == OPind))
{
return XP|JNE;
}
return (op >= OPbt && op <= OPbts) ? JC : JNE;
}
------------
How to fix this?
(1) Duplicate the if(tyfloating) code in the first return, so that floating
point CSEs still include a JP. But that penalizes the general case.
(2) Don't detect if(x) as a CSE, when x is floating point. One way of doing
this would be to change it into x!=0.
(3) Entirely disallow if (x) for floating point, generating an error in the
front end.
Personally I think (3) is the best. I think making 'if (nan)' true leads to
subtle bugs, and making it false also leads to subtle bugs.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list