Fix the underlying problem that was causing read(0) to be called: sometimes the

bitcode writer would generate abbrev records saying that the abbrev should be
filled with fixed zero-bit bitfields (this happens in the .bc writer when 
the number of types used in a module is exactly one, since log2(1) == 0).

In this case, just handle it as a literal zero.  We can't "just fix" the writer
without breaking compatibility with existing bc files, so have the abbrev reader
do the substitution.

Strengthen the assert in read to reject reads of zero bits so we catch such 
crimes in the future, and remove the special case designed to handle this.

llvm-svn: 174801
This commit is contained in:
Chris Lattner
2013-02-09 07:07:29 +00:00
parent 1420fda82f
commit 6c29cb3b7a
2 changed files with 16 additions and 5 deletions

View File

@@ -288,9 +288,20 @@ void BitstreamCursor::ReadAbbrevRecord() {
}
BitCodeAbbrevOp::Encoding E = (BitCodeAbbrevOp::Encoding)Read(3);
if (BitCodeAbbrevOp::hasEncodingData(E))
Abbv->Add(BitCodeAbbrevOp(E, ReadVBR64(5)));
else
if (BitCodeAbbrevOp::hasEncodingData(E)) {
unsigned Data = ReadVBR64(5);
// As a special case, handle fixed(0) (i.e., a fixed field with zero bits)
// and vbr(0) as a literal zero. This is decoded the same way, and avoids
// a slow path in Read() to have to handle reading zero bits.
if ((E == BitCodeAbbrevOp::Fixed || E == BitCodeAbbrevOp::VBR) &&
Data == 0) {
Abbv->Add(BitCodeAbbrevOp(0));
continue;
}
Abbv->Add(BitCodeAbbrevOp(E, Data));
} else
Abbv->Add(BitCodeAbbrevOp(E));
}
CurAbbrevs.push_back(Abbv);