Eli,<br><br>  Thanks for responding. Yes, I read the error message but it seems odd that it would be trying to use more than 64 bits. It compiles and executes in gcc on 32 bit arch just fine. I'll probably take your suggestion and file a bug with a reduced testcase.<br>
<br>Thanks again,<br><br>Ryan<br><br><div class="gmail_quote">On Fri, Nov 16, 2012 at 3:10 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Nov 16, 2012 at 3:00 PM, Ryan Taylor <<a href="mailto:ryta1203@gmail.com">ryta1203@gmail.com</a>> wrote:<br>

> Was hoping it might get some help or a better explanation of this:<br>
><br>
> /ADT/APInt.h:1217: uint64_t llvm::APInt::getZExtValue() const: Assertion<br>
> `getActiveBits() <= 64 && "Too many bits for uint64_t"' failed.<br>
<br>
</div>The error message is exactly what it says: you're trying to call<br>
getZExtValue() on an APInt whose value doesn't fit into a uint64_t.<br>
<div><div class="h5"><br>
> Program received signal SIGABRT, Aborted.<br>
> 0x00007ffff6eb4d05 in raise (sig=6) at<br>
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64<br>
> 64    ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.<br>
>     in ../nptl/sysdeps/unix/sysv/linux/raise.c<br>
> (gdb) bt<br>
> #0  0x00007ffff6eb4d05 in raise (sig=6) at<br>
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64<br>
> #1  0x00007ffff6eb8ab6 in abort () at abort.c:92<br>
> #2  0x00007ffff6ead7c5 in __assert_fail (<br>
>     assertion=0x7ffff6c7c907 "getActiveBits() <= 64 && \"Too many bits for<br>
> uint64_t\"",<br>
>     file=<value optimized out>, line=1217, function=<value optimized out>)<br>
> at assert.c:81<br>
> #3  0x00007ffff6c6c5cf in getZExtValue (this=<value optimized out>)<br>
>     at /home/ryan/llvm/llvm_core/trunk/include/llvm/ADT/APInt.h:1217<br>
> #4  getZExtValue (this=<value optimized out>)<br>
>     at /home/ryan/llvm/llvm_core/trunk/include/llvm/Constants.h:117<br>
> #5  cdfgPassClass::storeInstr (this=<value optimized out>) at<br>
> a2c_pass.cpp:2125<br>
> #6  0x00007ffff6c73dc1 in (anonymous namespace)::CDFGPass::runOnModule<br>
> (this=0x16c2fa0,<br>
>     M=<value optimized out>) at a2c_pass.cpp:2949<br>
> #7  0x0000000000f4cd4e in llvm::MPPassManager::runOnModule(llvm::Module&) ()<br>
> #8  0x0000000000f4d813 in llvm::PassManagerImpl::run(llvm::Module&) ()<br>
> #9  0x0000000000f4d94a in llvm::PassManager::run(llvm::Module&) ()<br>
> #10 0x0000000000525509 in main ()<br>
><br>
> Also, why does it give <value optimized out>, when I print the value I<br>
> clearly get one, unless this is some result of const prop?<br>
<br>
</div></div>No clue how gdb decides these things.  If you file a bug with a<br>
reduced testcase, someone might find the answer.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Eli<br>
</font></span></blockquote></div><br>