Re: Bug with logical operator or misunderstanding?

["David J. Slate" <dslate@...>]

Subject: Re: Bug with logical operator or misunderstanding?
Reply-To: dslate@speakeasy.net
To: lua-l@lists.lua.org

I haven't inspected the Lua internals code that handles these expressions,
but based on my experience this bug certainly has the look and feel of an
optimizer problem.  Optimization is nice, but better to have "larger,
slower, but apparently correct, code" than fast incorrect code!

For fans of ancient computer lore, I offer this anecdote:

Around 40 years ago I was working on Control Data Corporation's 6000/Cyber
series of computers.  At the time CDC had a Fortran compiler called, for
arcane reasons, "RUN".  RUN sometimes generated bad code, and from time to
time CDC issued patches to try to fix the offending sections of the
compiler.  However, these patches never seemed to completely resolve the
problem, and eventually CDC announced that the whole collection of these
patches had basically just piled new bugs on top of the old ones, and they
retracted all of them.  They finally "fixed" RUN by replacing it with a
completely redesigned compiler called "FTN".

I am hopeful that Lua will not suffer the same ill fate as "RUN".


On Sat, 22 Jan 2011 20:33:44 -0800 Sean Bolton <sean@smbolton.com> wrote:

> On Jan 22, 2011, at 11:09 AM, David J. Slate wrote:
> > One would hope that fixing this bug would be a priority for finishing
> > up Lua-5.2 and LuaJIT-2.0.
> 
> Yes.  It would be good to get confirmation from Rio and
> Mike Pall, that they understand this is still an
> outstanding bug.  The comment in the Lua 5.2.0-alpha test
> suite (constructs.c, lines 25-27) hints that this was
> considered an "old bug" (i.e., a fixed bug), yet the test
> cases there only test for one of the three distinct
> (known) expression patterns that cause the faulty results.
> 
> The patch at http://www.lua.org/bugs.html#5.1.4-3, which
> has been applied in Lua 5.2.0-alpha, fixes this case:
> 
> Lua 5.1.4  Copyright (C) 1994-2008 Lua.org, PUC-Rio
>  > print((1 or false) and true or false)
> 1    -- Wrong! (Lua 5.2.0-alpha correctly prints 'true')
> 
> The patch, however, does not fix the following two:
> 
> Lua 5.2.0 (alpha)  Copyright (C) 1994-2010 Lua.org, PUC-Rio
>  > print((1 or 2) and true or false)
> 1    -- should print 'true'!
> >
> 
>  > print((nil and true) or false and true)
> nil  -- should print 'false'!
> 
> The Lua 5.2.0-alpha test suite appears to test for that
> last expression with this line:
> 
> assert((((nil and true) or false) and true) == false)
> 
> but actually doesn't, since the extra parentheses change
> the meaning of the expression (remember 'and' has a
> higher precedence than 'or').
> 
> I've tried to figure out a fix, but I don't understand
> Lua internals enough yet.  I have found that the attached
> patch fixes all three of the problem expressions, but
> does so by disabling the optimization normally done to
> them. In other words, it causes the compiler to emit
> larger, slower, but apparently correct, code.
> 
> HTH,
> 
> -Sean
> 
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: lua-5.1.4-no_logical_op_opt.patch
> Type: application/octet-stream
> Size: 988 bytes
> Desc: not available
> Url : http://vlists.pepperfish.net/cgi-bin/mailman/private/lua-l-lists.lua.org/attachments/20110122/5564f446/lua-5.1.4-no_logical_op_opt-0001.obj