[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