[LLVMbugs] [Bug 1816] New: APInt::countTrailingZeros() > APInt::getBitWidth()
bugzilla-daemon at cs.uiuc.edu
bugzilla-daemon at cs.uiuc.edu
Wed Nov 21 11:38:00 PST 2007
http://llvm.org/bugs/show_bug.cgi?id=1816
Summary: APInt::countTrailingZeros() > APInt::getBitWidth()
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: Core LLVM classes
AssignedTo: unassignedbugs at nondot.org
ReportedBy: nlewycky at google.com
CC: llvmbugs at cs.uiuc.edu
APInt's "countTailingZeros" function is either buggy, or at best misleading.
Consider the following standalone program (link with LLVM core):
#include <iostream>
#include "llvm/ADT/APInt.h"
int main() {
llvm::APInt myint = llvm::APInt::getNullValue(290);
uint32_t zeros = myint.countTrailingZeros();
std::cout << zeros << "\n";
}
So, how many "trailing zeros" are there in a 290-bit integer?
320.
What's slightly worrying is that this behaviour is documented. The
documentation http://llvm.org/doxygen/classllvm_1_1APInt.html#z9_9 says
"Returns: getNumWords() * APINT_BITS_PER_WORD if the value is zero."
So the code matches the documentation, but I'm thinking that both are wrong
here. It doesn't make sense for it to return a value greater than its BitWidth.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list