[LLVMdev] [NVPTX] Strange assertion around BlockToChain.clear(); in Release+Asserts build

[Justin Holewinski]

Unfortunately, I cannot reproduce this.  Based on your bugzilla comment, 
it does look like a mis-compile with your system compiler. Does the same 
issue occur if you build LLVM as static libraries?

On 08/03/2012 12:24 AM, Dmitry N. Mikushin wrote:
> Dear NVPTX community,
>
> I've create a bug http://llvm.org/bugs/show_bug.cgi?id=13521 with
> reprocase for this issue.
>
> Please, help us to fix it. Last 1,5 months we regularly encounter &
> workaround or fix 1-2 bugs per week in NVPTX backend. This is
> definitely not the amount of work we can completely serve ourselves...
> We would really really appreciate some collaboration.
>
> Thanks,
> - D.
>
> 2012/8/3 Dmitry N. Mikushin <maemarcus at gmail.com>:
>> Hi,
>>
>> After building out project in release mode, caught an assertion, which
>> we have not seen before:
>>
>> hello_f: /tmp/rpmbuild_debug/BUILD/llvm/build/include/llvm/ADT/DenseMap.h:126:
>> void llvm::DenseMap<KeyT, ValueT, KeyInfoT>::clear() [with KeyT =
>> llvm::MachineBasicBlock*, ValueT = <unnamed>::BlockChain*, KeyInfoT =
>> llvm::DenseMapInfo<llvm::MachineBasicBlock*>]: Assertion `NumEntries
>> == 0 && "Node count imbalance!"' failed.
>>
>> Program received signal SIGABRT, Aborted.
>> 0x00007ffff785c945 in raise () from /lib64/libc.so.6
>> (gdb) bt
>> #0  0x00007ffff785c945 in raise () from /lib64/libc.so.6
>> #1  0x00007ffff785df21 in abort () from /lib64/libc.so.6
>> #2  0x00007ffff7855810 in __assert_fail () from /lib64/libc.so.6
>> #3  0x00007ffff62b283d in (anonymous
>> namespace)::MachineBlockPlacement::runOnMachineFunction(llvm::MachineFunction&)
>> () from /opt/kernelgen/lib/libLLVM-3.2svn.so
>> #4  0x00007ffff64cfb9f in
>> llvm::FPPassManager::runOnFunction(llvm::Function&) () from
>> /opt/kernelgen/lib/libLLVM-3.2svn.so
>> #5  0x00007ffff64cfc43 in
>> llvm::FPPassManager::runOnModule(llvm::Module&) () from
>> /opt/kernelgen/lib/libLLVM-3.2svn.so
>> #6  0x00007ffff64cf6e4 in
>> llvm::MPPassManager::runOnModule(llvm::Module&) () from
>> /opt/kernelgen/lib/libLLVM-3.2svn.so
>> #7  0x00007ffff64cf840 in llvm::PassManagerImpl::run(llvm::Module&) ()
>> from /opt/kernelgen/lib/libLLVM-3.2svn.so
>> #8  0x00007ffff75aa57a in TrackedPassManager::run
>> (this=0x7fffffffc8d0, M=...) at ../bugpoint/TrackedPassManager.h:168
>> #9  0x00007ffff75a66bf in kernelgen::runtime::codegen (runmode=1,
>> kernel=0x7fffffffd420, m=0x833ab0) at codegen.cpp:454
>> #10 0x00007ffff75871b1 in main (argc=1, argv=0x7fffffffdcc8,
>> envp=0x7fffffffdcd8) at entry.cpp:318
>> #11 0x00007ffff7848bc6 in __libc_start_main () from /lib64/libc.so.6
>> #12 0x00000000004008f9 in _start () at ../sysdeps/x86_64/elf/start.S:113
>>
>> Any ideas?.. What could it be related to?
>>
>> Thanks,
>> - D.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- 
Thanks,

Justin Holewinski