parser bug?

[regehr]

Take this query:

%0:i8 = var
%1:i1 = eq %0, 1
%2:i1 = eq %0, 2
%3:i1 = eq %0, 4
%4:i1 = eq %0, 8
%5:i1 = eq %0, 16
%6:i1 = eq %0, 32
%7:i1 = eq %0, 64
%8:i1 = eq %0, 128
%9:i1 = or %1, %2, %3, %4, %5, %6, %7, %8
infer %9

%20:i8 = ctpop %0
%21:i1 = eq %20, 1
result %21

Parse and print it, and the result is:

%0:i8 = var
%1:i1 = eq 1:i8, %0
%2:i1 = eq 2:i8, %0
%3:i1 = eq 4:i8, %0
%4:i1 = eq 16:i8, %0
%5:i1 = eq 32:i8, %0
%6:i1 = eq 64:i8, %0
%7:i1 = eq 128:i8, %0
%8:i1 = eq 248:i8, %0
%9:i1 = or %1, %2, %3, %4, %5, %6, %7, %8
%10:i8 = ctpop %0
%11:i1 = eq 1:i8, %10
cand %9 %11

[regehr]

Even after we fix this, we need a way to flush out bugs of this type. I'm thinking perhaps a Souper loopback mode where every query is put through a print/parse RT.

[regehr]

Valgrind is silent so it's likely a logic error and not memory unsafety.

I haven't looked into this bug yet and won't do it tonight.

[chenyang78]

I created a pull request #125 to address this issue.