RE: code generation bug
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: RE: code generation bug
- From: "Kelley, Brian" <bkelley@...>
- Date: Thu, 7 May 2009 16:14:04 -0700
> Not surprisingly, the dual case has the same bug:
>
> > = ((nil and true) or false) and true
> nil
> > f=false
> > = ((nil and true) or f) and true
> false
Or more generally, for any Y, Z:
((nil and Y) or false) and Z --> nil
(nil and Y) or (false and Z) --> nil
Which is symmetrical with my earlier generalization: For any X, Y, Z, where X ~=nil and X~=false:
((X or Y) and true) or Z --> X
(X or Y) and (true or Z) --> X
> > For what it's worth, I observed in lcode.c that the OPR_AND
> expression
> > inherited the 'k' (kind) of VTRUE from its rhs subexpression,
> > which seems wrong and seems to throw off the subsequent call to
> > luaK_goiffalse().
>
> Well, the result of "((1 or false) and true)" is true, so the
> inherited
> attribute VTRUE is not completely wrong. The problem seems to be the
> interaction between this attribute and the patch lists. (But I still
> need some time to check this bug...)
Got it. I didn't have time to grok the code generation, but offered this info in case it might help a bit.
-bhk