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

[Dmitry N. Mikushin]

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.

2012/8/3 Justin Holewinski <justin.holewinski at gmail.com>:
> 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
>