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


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
() from /opt/kernelgen/lib/libLLVM-3.2svn.so
#4 0x00007ffff64cfb9f in
llvm::FPPassManager::runOnFunction(llvm::Function&) () from
#5 0x00007ffff64cfc43 in
llvm::FPPassManager::runOnModule(llvm::Module&) () from
#6 0x00007ffff64cf6e4 in
llvm::MPPassManager::runOnModule(llvm::Module&) () from
#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?

- D.

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.

- D.

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?

Hi Justin,

Thanks for checking. Yes, I marked bug invalid because it is only
reproducable with quite old version of gcc. This incident motivated us
to switch onto full bootstrapping in our project build process. So we
can count this report as gcc issue and close it.

- D.