http://d.puremagic.com/issues/show_bug.cgi?id=3918



--- Comment #3 from Don <clugd...@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: -------

Reply via email to