hefeix / szl Goto Github PK

In ProcessCommandLineArguments, strtol's endptr is checked for '\0' to make 
sure the integer parsing didn't end on an error, but it doesn't check the 
corner case that the string is entirely empty.  Empty-string is not an integer.

On some platforms, errno is set to a nonzero value when this happens, but if 
you want to rely on that, why use endptr at all?

The patch fixes it by entering the error branch if the value is the empty 
string.

I've extracted szl source and configured it. Then I tried top run `make'.

I expected to have szl compiled, but instead I 've seen the following:

engine/symboltable.cc:47:1: error: ‘sawzall::Proc::Proc’ names the 
constructor, not the type

I've tried to compile szl on OpenSUSE 11.3 x86_64 (kernel 2.6.35) with gcc 4.5 
and protoc 2.3.

When I edited engine/symboltable.cc (see attached patch), the code was compiled 
successfully. I could not test if the compiler runs properly because I could 
not find a single Sawzall tutorial on the web.

After modifying ``configure.ac`` and rerunning ``autoreconf -f``, ``svn`` 
reports the following:

    $ svn status | grep ^M
    M       configure
    M       Makefile.in
    M       src/Makefile.in
    M       configure.ac
    M       aclocal.m4

All files above are generated from ``configure.ac``, so I think there's no need 
to keep them in Subversion.

Compiling on Ubuntu 10.4 (32 bit):

    make[3]: Entering directory `/home/carlos/src/szl-svn/protobuf-location/src'
    /bin/bash ../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I..   -pthread -I/opt/protobuf/2.3.0/include    -pthread -g -O2 -g -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -DNDEBUG -pthread -O2 -DSZL_BIG_ENDIAN=1 -DSZL_LITTLE_ENDIAN=2 -DSZL_BYTE_ORDER=2 -g -O1 -pthread -g -O2 -g -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -DNDEBUG -MT analyzer.lo -MD -MP -MF .deps/analyzer.Tpo -c -o analyzer.lo `test -f 'engine/analyzer.cc' || echo './'`engine/analyzer.cc
    libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -pthread -I/opt/protobuf/2.3.0/include -pthread -g -O2 -g -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -DNDEBUG -pthread -O2 -DSZL_BIG_ENDIAN=1 -DSZL_LITTLE_ENDIAN=2 -DSZL_BYTE_ORDER=2 -g -O1 -pthread -g -O2 -g -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -DNDEBUG -MT analyzer.lo -MD -MP -MF .deps/analyzer.Tpo -c engine/analyzer.cc  -fPIC -DPIC -o .libs/analyzer.o
    In file included from ./engine/globals.h:20,
                     from engine/analyzer.cc:20:
    ./public/porting.h:51: error: conflicting declaration �typedef long unsigned int uintptr_t�
    /usr/include/stdint.h:129: error: �uintptr_t� has a previous declaration as �typedef unsigned int uintptr_t�
    make[3]: *** [analyzer.lo] Error 1
    make[3]: Leaving directory `/home/carlos/src/szl-svn/protobuf-location/src'
    make[2]: *** [all] Error 2
    make[2]: Leaving directory `/home/carlos/src/szl-svn/protobuf-location/src'
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/home/carlos/src/szl-svn/protobuf-location'
    make: *** [all] Error 2

The attached diff skips the typedef if ``stdint.h`` has been found: It seems 
that C99 specifies that type (http://en.wikipedia.org/wiki/Stdint.h)

The default values for the --protocol_compiler and --protocol_compiler_plugin 
path point to /usr/local. These paths should depend on the result of running 
configure.

The attached patch achieves it.

As of r33, the configure script asumes protobuf is installed on standard 
locations (headers under /usr/include, libraries under /usr/bin).

If ``pkg-config`` is installed, one can always do the following:

  $ env CPPFLAGS="$(pkg-config --cflags protobuf)" \
        LIBS="$(pkg-config --libs protobuf)" \
            ./configure [..]

The attached diff eliminates the need to do that, and simplifies a bit 
``configure.ac`` -- it also makes building ``szl`` depend on ``pkg-config``, 
though.

elfgen_unittest.cc is hard-coded to expect 64-bit length addresses from objdump 
text output.  On 32-bit platforms the string is shorter and has leading zeros 
and extra trailing garbage.  

actual="094d5b3a l     F        " 
expected="00000000094d5b3a "

Some of my testing environments are hitting this failed assertions in  the 
szlbootstrapsum unittest.  I suspect this is due to direct equality comparison 
of floating point values.

complie error

engine/code.cc: In static member function ‘static void 
sawzall::Code::MemMapCode(sawzall::Instr*, size_t, sawzall::Instr**, 
size_t*)’:
engine/code.cc:364:48: error: ‘getpagesize’ was not declared in this scope
make[3]: *** [code.lo] Error 1
make[3]: Leaving directory `/data/opencode/szl/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/data/opencode/szl/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/data/opencode/szl'
make: *** [all] Error 2

 3.2.0-4-686-pae #1 SMP Debian 3.2.35-2 i686 GNU/Linux
gcc --version
gcc (Debian 4.7.2-5) 4.7.2

Ubuntu natty has changed the default ld flags to include --as-needed, which 
only links in libraries detected as used:

https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/031991.html

Consequently, szl's intrinsics and extensions libraries do not get linked in, 
and you you get all kinds of errors:

$ src/szl -e 'emit stdout <- string(fabs(-1.1));'
<commandline>:1: fabs undeclared

To fix, I need to make autoconf detect GNU ld and add -Wl,--no-as-needed to the 
LDFLAGS.

When szl is built with NDEBUG, it asserts:

lt-szl: engine/nativesupport.cc:1372: static void 
sawzall::NSupport::AllocStatics(sawzall::Proc*, size_t): Assertion 
`proc->state_.sp_ == proc->state_.fp_->stack()' failed.

e.g.:

$ src/szl -e 'emit stdout <- "Hello";'
(assertion)
Aborted

Hi, 

You have a typo that isn't including malloc.h header in src/engine/memory.cc. 
It should be HAVE_MALLINFO and not HAVE_MALLINGO.

src/engine/memory.cc:
[...]
#ifdef HAVE_MALLINGO
#include <malloc.h>   // for mallinfo()
#endif
[...]
#ifdef HAVE_MALLINFO
    struct mallinfo info = mallinfo();
    // Ack, limited to 4GB.  Stored as "int", make sure we use full 32 bits.
    int64 freespace = static_cast<unsigned int>(info.fordblks);
    // As we get closer to running out of process memory, get more aggressive
    // about requiring that malloc space is available to minimize the chance
    // that we will run out of process memory.
    // (If we seem to have enough, do nothing and hope malloc succeeds.)
#else
    int freespace = 0;
#endif
[...]

What steps will reproduce the problem?
1. Run the command: "src/szl example1.szl"
2.
3.

What is the expected output? What do you see instead?
I am intentionally not providing an input datafile; normally I'd expect a 
syntax error, but instead I get a Segfault.

What version of the product are you using? On what operating system?
I am on Ubuntu 10.04, 32bit, Intel x86

Please provide any additional information below.
1)
The stacktrace is as follows:
#0  0x004b7fd3 in ?? ()
#1  0x00bb54d4 in sawzall::Proc::Execute (this=0x9f44168, max_steps=2147483647, 
num_steps=0x0) at engine/proc.cc:403
#2  0x00bc08fe in sawzall::Process::Execute (this=0xbff18ca0, 
max_steps=2147483647, num_steps=0x0) at engine/sawzall.cc:636
#3  0x00bc1488 in sawzall::Process::Run (this=0xbff18ca0, input_ptr=0x804de94 " 
", input_size=0, key_ptr=0x804de94 " ", key_size=0) at engine/sawzall.cc:669
#4  0x00bc154e in sawzall::Process::RunOrDie (this=0xbff18ca0, 
input_ptr=0x804de94 " ", input_size=0, key_ptr=0x804de94 " ", key_size=0) at 
engine/sawzall.cc:689

2)
BTW, when I generated bytecode instead of native code it works fine. That is:
src/szl example1.szl -native=false
works correctly...

Their base class SzlTabEntry has member tot_elems_ so no need to redefine.

PATCH:
Index: src/emitters/szlmaximum.cc
===================================================================
--- src/emitters/szlmaximum.cc  (revision 53)
+++ src/emitters/szlmaximum.cc  (working copy)
@@ -91,7 +91,6 @@
       return sizeof(SzlMaximumEntry) + heap_.Memory() + sizeof(SzlValueCmp);
     }

-    virtual int64 TotElems() const { return tot_elems_; }
     virtual int TupleCount() { return heap_.nElems(); }

     const SzlOps& weight_ops() const  { return weight_ops_; }
@@ -103,9 +102,6 @@
     // TODO: Add an iterator for sorted output to improve
     // FlushForDisplay performance.
     SzlHeap heap_;
-
-    // Total elements ever added to the table.
-    int64 tot_elems_;
   };
 };

Index: src/emitters/szlquantileresults.cc
===================================================================
--- src/emitters/szlquantileresults.cc  (revision 53)
+++ src/emitters/szlquantileresults.cc  (working copy)
@@ -89,14 +89,11 @@

   virtual const vector<string>* Results()  { return &quantiles_; }

-  virtual int64 TotElems() const  { return tot_elems_; }
-
  private:
   SzlType type_;  // the type of the table
   SzlOps ops_;   // Operations on our element type, for parsing.
   vector<string> quantiles_;
   const int num_quantiles_;
-  int64 tot_elems_;

   void Clear() {
     quantiles_.clear();

Please mention something like this on the first page.
$ szl --table_output='*' example.szl input.txt

The regression tests sort/sort_0{1,2,3,4}.szl all fail in -N (native) mode on 
x86_64 Ubuntu 13.04 when compiled with -O1 or higher. Compiling 
nativecodegen.cc with -O0 is a workaround.

The root cause appears to be that FunctionCall (a class defined in 
nativecodegen.cc) copies a reference-typed constructor argument to a 
reference-typed member variable, and then accesses it in ~FunctionCall after 
the original constructor argument has been deallocated by the caller. To put it 
another way, each FunctionCall retains a pointer to a stack object and 
dereferences it after its lifetime has expired. The decision to use '&' instead 
of '*' rendered the bug difficult to see on code review.

One-byte code patch attached, representing two days of debugging work. Two 
days. One byte. This is why I hate C++.

The szl_regtest.sh test base/include_b.szl is broken; it should not pass.
The szl_regtest.sh support script ./update has a bug which masks the brokenness.

The test apparently is intended to work like so:
 - base/include_b.szl loads and executes base/include_dir/a.szl
 - a.szl includes b.szl
 - b.szl declares a variable x
 - base/include_b.szl assigns to x (thereby checking that b.szl was successfully executed)

However, this cannot work as (apparently) intended because include_b.szl uses 
the load() builtin to load a.szl, and load() does not attempt to execute or 
otherwise interpret the bytes that it loads. Ref: 
http://szl.googlecode.com/svn/doc/sawzall-intrinsics.html

The test harness support script src/engine/language_tests/update has a large 
shell-case-statement with special settings for different test sources. The case 
for base/include_b.szl inserts "base/include_dir/a.szl" into the $sources 
variable. However, only the first word in that variable is used as the szl 
program; subsequent words are used as input data filenames. The effect of all 
this is that the test executes a.szl and ignores include_b.szl.

I am at a loss to recommend a fix, as the whole test appears to be a confusion 
of ideas complicated by a confused idea. I recommend deleting all three files 
unless the author has a better idea.

OS :  x86_64 GNU/Linux
App : szl 1.0 （http://code.google.com/p/szl/downloads/list）

Input :The input file is recordio format which is offer by szl, with 100 
records in it. Each record has channel field, bug only 92 records have 
refer_info.g_f.

Script : case_ok.szl, case_bad1.szl, base_bad2.szl

Question : the three cases are suppose to have same result , but it is not.

Case 1：
    Input sawzall script :(case_ok.szl)
    .....
      1 proto "log_wap_access.proto"
      2 
      3 pv_channel : table sum[channel:bytes] of int;
      4 
      5 log : log_wap_access = input;
      6 channel: bytes = ?{if(def(log.channel)) result log.channel; else result B"";};
      7 emit pv_channel[channel] <- 1;
    ....

    Input data :(input)
    Run command :./szl case_ok.szl input --use_recordio=true --protocol_compiler=./protoc --protocol_compiler_plugin=./protoc-gen-szl --table_output=*
    Result :   pv_channel[WAP_SWEB_ACS] = 100


Case 2:
    Input sawzall script :(case_bad1.szl)
      ....
      1 proto "log_wap_access.proto"
      2 
      3 pv_channel : table sum[channel:bytes] of int;
      4 
      5 log : log_wap_access = input;
      6 channel: bytes = ?{if(def(log.channel)) result log.channel; else result B"";};
      7 emit pv_channel[channel] <- 1;
      8 
      9 # this variable is not used
     10 usless : uint = log.refer_info.g_f;
    ....
    Input data :(input)
    Run command :./szl case_bad1.szl input --use_recordio=true --protocol_compiler=./protoc --protocol_compiler_plugin=./protoc-gen-szl --table_output=*
    Result:     pv_channel[WAP_SWEB_ACS] = 92
    pv_channel[] = 8

Case 3:
    Input sawzall script :(case_bad2.szl)
      ....
      1 proto "log_wap_access.proto"
      2 
      3 pv_channel : table sum[channel:bytes] of int;
      4 
      5 # this variable is not used
      6 usless_table : table collection of log_wap_access;
      7 
      8 log : log_wap_access = input;
      9 channel: bytes = ?{if(def(log.channel)) result log.channel; else result B"";};
      10 emit pv_channel[channel] <- 1;
    ....
    Input data :(input)
    Run command :./szl case_bad2.szl input --use_recordio=true --protocol_compiler=./protoc --protocol_compiler_plugin=./protoc-gen-szl --table_output=*
    Result:     pv_channel[WAP_SWEB_ACS] = 92
    pv_channel[] = 8

What steps will reproduce the problem?
1. Run configuration script on Mac OS X with Xcode installed:
    ./configure

What is the expected output? What do you see instead?

Expecting ./configure generates Makefiles.

What version of the product are you using? On what operating system?

./configure failed with the following outputs:

checking for objdump... no
configure: error: in `/Users/wangyi/svnclient/szl-read-only':
configure: error: no objdump utility was found (required for elfgen_unittest)

Please provide any additional information below.

objdump is from GNU tools and mostly used with Linux, but Mac OS X inherits 
user space programs from BSD.  Is it possible to make configure choose otool, 
instead of objdump, on Mac OS X?

Here's an "svn diff" patch to fix the multiple minor problems (mostly 
linuxisms) that stopped it from building on FreeBSD.  With this patch, "gmake 
check" passes.  I've tried to rely on only standard features wherever possible, 
but on some of the scripts I wussed out and said "run bash" instead.

Summary of changes:
- Prefer standard POSIX shell constructs where possible:
  - Bash isn't necessarily in /bin (FreeBSD puts it in /usr/local/bin);
  - expr-matching instead of grep <<< string;
  - case-statement instead of == inside [[ ]];
  - "foo()" instead of "function foo";
  - "for (( s1; expr; s2 ))" is not supported;
  - "$SZL" in command position isn't always expanded correctly [actually, I'm not sure about this since I found some instances of $"$SZL" that might explain the odd error messages]; and
  - in test statements, "-eq" instead of "==".
- Detect at configure time whether va_copy is supported, and if so use it 
instead of trying to use __va_copy.
- Use a union type to effect reinterpret-casting between double and unsigned 
long long; the pointer-reinterpretation approach failed disastrously with the 
requested -O2 -fstrict-aliasing flags, causing incorrect values to come out of 
the cast.
- On systems without ieee754.h (e.g. FreeBSD), generate random floats and 
doubles by multiplying the minimum representable value >1 by a random integer 
to get an exactly-representable value.  I microbenchmarked this and found it to 
be a tiny bit faster than the existing 
fill-a-struct-of-bitfields-and-reinterpret-cast approach.  Oddly, it returned 
the same values given the same random seed; you might consider using it even if 
ieee754.h is available.
- An abs() call had an ambiguous type since it had definitions available for 
int and long, but not for long long which was the actual arg type.  Replaced 
with llabs().
- The declaration of uintptr_t clashed with the slightly different declaration 
in the standard library, so it was made conditional on an autoconf check.
- ACX_USE_SYSTEM_EXTENSIONS doesn't exist, and that first X is probably a typo. 
 Read the ./configure output next time! :-)

Happy patching!

 --Adrian.
who/aecolley

Full build log is attached, jump to the first check-TESTS reference. 

I'm using a Debian sid chroot to build.

What steps will reproduce the problem?
1. ./configure
then broken 

What is the expected output? What do you see instead?

error info:

checking protobuf header version... yes (2.3.0 or later)
checking for protobuf library... yes
checking for protocol compiler library... configure: error: in 
`/home/xyz/code/szl':
configure: error: no working protocol compiler library was found
See `config.log' for more details.

but i have  successfully installed protocol buffer  in  /usr/bin/protoc.

whereis protoc
protoc: /usr/bin/protoc /usr/local/bin/protoc /usr/share/man/man1/protoc.1.gz

What version of the product are you using? On what operating system?
szl-1.0.tar.gz  ubuntu

Please provide any additional information below.

spelling error.

Native mode on linux x86_64 stack traces fail to terminate at the $main or 
$init frame as documented; they continue and produce "no symbolic frame 
information (initialization frame?)" for non-nativecodegen C++ stack frames.

The underlying problem is the incorrect assumption that the stack always grows 
downward with the same layout. This assumption is made in frame.cc:

bool FrameIterator::is_valid() const {
  if (native_)
    return sp() <= proc()->native_bottom_sp();
  [...]
}

In practice, the top szl frame has sp() == proc()->native_bottom_sp(), but 
often the next few C++ frames have values in the "sp" slot which are 
numerically less than the nativecodegen's bottom_sp. FrameIterator::is_valid 
misidentifies them as valid szl native frames.

Walking through memory, deferencing pointers at random, seems dangerous in 
itself. That's why this is a separate bug and not just part of issue 19.

According to a comment in ``sawzall.h``, the following files are Sawzall's 
public interface:

   porting.h
   sawzall.h
   emitterinterface.h
   szltype.h
   szlvalue.h
   szlresults.h
   szlencoder.h
   szldecoder.h
   szlnamedtype.h
   value.h

Some of those files, however, do a ``#include "public/szltype.h"``, which does 
not work outside Sawzall's source tree.

The attached diff addresses this by removing the ``#include 
"public/szltype.h"`` line from the header files, and adding it to the source 
files that need it.

I don't like the fact that now the order of included files matters (you have to 
include ``szltype.h`` before including ``szlresults.h``, for instance). Any 
idea on a better approach?

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

From a chroot:

# szl hw2.szl
[FATAL sysutils.cc:79] assertion failed: CHECKGE(fd,0)
Aborted

# mount -t proc proc /proc

# szl hw2.szl 
Hello, World!


src/utilities/sysutils.cc:78
  int fd = open("/proc/meminfo", O_RDONLY);
  CHECK_GE(fd, 0);


I think something like the line below at 79 would work better:
CHECK_GE(fd,0) << ": Is proc mounted?";

Compiling with clang fails with:
engine/symboltable.cc:47:7: error: qualified reference to 'Proc' is a 
constructor name rather than a type wherever a cons
Proc::Proc* SymbolTable::init_proc_ = NULL;



This patch fixes the issue, tested on OS X 10.9, Xcode 5.1:

diff --git a/src/engine/symboltable.cc b/src/engine/symboltable.cc
index 6d84592..71965f3 100644
--- a/src/engine/symboltable.cc
+++ b/src/engine/symboltable.cc
@@ -44,7 +44,7 @@ namespace sawzall {
 // ------------------------------------------------------------------------------
 // Implementation of SymbolTable

-Proc::Proc* SymbolTable::init_proc_ = NULL;
+Proc* SymbolTable::init_proc_ = NULL;

 List<TableType*>* SymbolTable::table_types_ = NULL;
 TableType* SymbolTable::collection_type_ = NULL;

I have get a new problem after run "./configure" successfully.

$ sudo make

make  all-recursive
make[1]: Entering directory `/home/xyz/code/szl'
Making all in .
make[2]: Entering directory `/home/xyz/code/szl'
make[2]: Leaving directory `/home/xyz/code/szl'
Making all in src
make[2]: Entering directory `/home/xyz/code/szl/src'
make[3]: Entering directory `/home/xyz/code/szl'
make[3]: Leaving directory `/home/xyz/code/szl'
oldpwd=`pwd` && ( cd . && /usr/local/bin/protoc -I. --cpp_out=$oldpwd 
emitvalues/sawzall.proto )
/usr/local/bin/protoc: error while loading shared libraries: libprotobuf.so.6: 
cannot open shared object file: No such file or directory
make[2]: *** [emitvalues/sawzall.pb.cc] Error 127
make[2]: Leaving directory `/home/xyz/code/szl/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/xyz/code/szl'
make: *** [all] Error 2


$ whereis libprotobuf.so.6
libprotobuf.so: /usr/lib/libprotobuf.so.5 /usr/lib/libprotobuf.so 
/usr/local/lib/libprotobuf.so.6 /usr/local/lib/libprotobuf.so

If you build a recent ICU4C library (4.8 or newer) with the recommended build 
settings, szl will:-

1. Fail to build because:-
  (a) the UnicodeString(const char *) constructor is now marked "explicit" in line with C++ good practice, so it now needs to be explicitly invoked in cases where implicit calls were made; and
  (b) references to TimeZone and UnicodeString need to be qualified (i.e. icu::UnicodeString). This is an optional-but-recommended build setting in ICU.
2. Fail to run correctly because calls to icu::TimeZone::createTimeZone now 
return the Etc/Unknown zone for unknown timezone IDs. Szl expects it to return 
the GMT zone (which ICU hasn't done since 4.7).

The fixes are simple. A patch is attached to this bug report. The existing 
engine/language_tests/intrinsics/time_01.szl test acts as a unit test. (It 
fails with szl r53 and icu 4.8.)

Consolidating various check-TESTS failures into a single issue:

*    emitter/tables_misc_good.szl:
: due to output sorting order with different standard libraries

*    [FATAL szlbootstrapsum_unittest.cc:141] assertion failed: 
CHECK(original[offset + 1].real + update[1].real == table[offset + 1].real)
: due to float comparison with ==

*    [FATAL elfgen_unittest.cc:99] assertion failed: CHECKEQ(actual,expected)
: on 32-bit platforms due to objdump text address output width

*    intrinsics/resourcestats-32.szl
: due to .err file having unknown flag warning

*    intrinsics/resourcestats-64.szl
> user CPU time variance percentage too high, actual: 112, expected range: [0, 
100]
: (user reported, 64-bit Debian sid build)

The attached diff adds pkg-config files for Sawzall's three libraries. Once 
applied, embedding Sawzall in programs like this one:

  //
  // test.cc
  //

  #include <google/szl/porting.h>
  #include <google/szl/commandlineflags.h>
  #include <google/szl/sawzall.h>


  int main(int argc, char **argv) {
    InitializeAllModules();
    sawzall::Executable exe(argv[1], NULL, sawzall::kNormal);
  }

is just a matter of running:

  $ g++ $(pkg-config --cflags szl) \
         szl-test.cc -o szl-test  \
        $(pkg-config --libs szl)

What steps will reproduce the problem?
1, code:
test_set: table set(1) of string;
emit test <- "A";
emit test <- "B";

What is the expected output? What do you see instead?
There is nothing output.

What version of the product are you using? On what operating system?
version 1.0.

Please provide any additional information below.
I saw this code of src/emitter/szlset.cc:
 55     virtual int AddElem(const string& elem) {                                                                                     
 56       tot_elems_++;                                                                                                               
 57       // Do not add if we are already full.                                                                                       
 58       if (set_.size() > maxElems_)  // Is this correct? Maybe '>='?                                                                                             
 59         return 0;                                                                                                                 
 60       if (set_.insert(elem).second)                                                                                               
 61         return kNodeSize + elem.size();                                                                                           
 62       return 0;                                                                                                                   
 63     }

ProcessCommandLineArguments (in utilities/commandlineflags.cc) recognizes 
"--no<flagname>" by comparing the known flagname with p[2..len+2], but it then 
incorrectly goes on to compare "p[len] == '='" in the rest of the function as a 
way of distinguishing "--flag=value" from "--flag value".

This goes wrong when the flag is boolean, "no" is present, and the "=value" is 
also present.  The handling of "false" and "true" for bool flags is intended to 
be inverted when "no" is present.  Unfortunately, the presence of "no" causes 
the code to fail to find the '=', and so it proceeds as if the "=value" was 
absent.  When the value is "true" this works out, but not when it's "false".

The patch adds 2 to len when the flag was recognized as "no" + a bool flag (and 
not, say, a bool flag happening to begin with no, such as "--notify").

OpcodeFor in ir.cc scans a static array (opcodetab) looking for a sentinel that 
isn't there. The upshot is memory corruption in --nonative mode.

I have no specific test for this, but the memory corruption problems suddenly 
went away when I noticed and fixed this bug.

The patched code respects a proper array bound on the loop control variable.