Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
7 years ago

Error: Assert failure at RegNodeInsertion.cpp(854)

Hi,

My design is made of NDRange kernels and runs correctly in emulation.

However, I cannot generate the report as I get the "Error: Assert failure at RegNodeInsertion.cpp(854)".

I have no idea where in the kernel to start looking for the error source as I do not understand the info the compiler provides.

Any suggestion on how to solve this? 


******* Error: Assert failure at RegNodeInsertion.cpp(854) *******
Register: REG (0x16ca770):
	Basic block: Block44 0x1775430
	Predecessors: 0x17b4970
	Successors: 0x11b5b70
	Value: 
	Cycle: 277 ==> 277
Successor: BARRIER  (0x11b5b70):
	Basic block: Block44 0x1775430
	Predecessors: 0x17b4f00 0x1794430 0x11951d0 0x12bcfc0 0x12bd170 0x12bd320 0x12bd850 0x12bd9e0 0x12bec70 0x121f2d0 0x1222a80 0x16ca770
	Successors: 0x17b5450 0x1198da0 0x17dcbf0 0x17dcd80 0x17dcf30 0x17dd0e0 0x17dd290 0x17dd440 0x17dd5f0 0x17dd7a0 0x17dd950
	Instruction: 
	Cycle: 279 ==> 280
	Barrier variables:          
succ_start_cycle <= reg_end_cycle FAILED
0  libLLVM-3.0.so  0x00007f1e8b61197f
1  libLLVM-3.0.so  0x00007f1e8b6138f2
2  libpthread.so.0 0x00007f1e8a5daaf0
3  libLLVM-3.0.so  0x00007f1e8bb774cd acl::RegNodeInsertion::split_multi_tap_reg_node(acl::CCDFGNode*) + 1517
4  libLLVM-3.0.so  0x00007f1e8bb784a5 acl::RegNodeInsertion::split_multi_tap_reg_nodes() + 1173
5  libLLVM-3.0.so  0x00007f1e8b9909e6 acl::CapacityBalancePass::runOnFunction(llvm::Function&) + 3014
6  libLLVM-3.0.so  0x00007f1e8b732e0f llvm::FPPassManager::runOnFunction(llvm::Function&) + 527
7  libLLVM-3.0.so  0x00007f1e8b732f70 llvm::FPPassManager::runOnModule(llvm::Module&) + 80
8  libLLVM-3.0.so  0x00007f1e8b732931 llvm::MPPassManager::runOnModule(llvm::Module&) + 577
9  libLLVM-3.0.so  0x00007f1e8b732adb llvm::PassManagerImpl::run(llvm::Module&) + 187
10 aocl-llc        0x000000000040bdc0 main + 5360
11 libc.so.6       0x00007f1e8957100a __libc_start_main + 234
12 aocl-llc        0x00000000004098e9
Stack dump:
0.	Program arguments: /opt/cad/altera/altera-16.0/hld/linux64/bin/aocl-llc -march=fpga -mattr=option3wrapper -fpga-const-cache=1 -board /home/wimi/lvs/BSP_AOC_GIDEL/Proc10A_16.0.2/hardware/Proc10A_X115/board_spec.xml -dbg-info-enabled calc_initpop.bc -o calc_initpop.v 
1.	Running pass 'Function Pass Manager' on module 'calc_initpop.bc'.
2.	Running pass 'Loop Capacity Balance Pass' on function '@perform_ls'
Error: Verilog generator FAILED.
Refer to calc_initpop/calc_initpop.log for details.

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    7 years ago

    Hopefully someone comes along with a more in depth answer but when I've received weird error messages like this I typically comment parts of my kernel out until I can isolate the line(s) of code that cause the error. Once you know the code or code style that is causing issues you can typically refactor it to be more compiler friendly.

    Have you been able to successfully build NDRange kernels previously on this machine with this version of the tool?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    7 years ago

    --- Quote Start ---

    Hopefully someone comes along with a more in depth answer but when I've received weird error messages like this I typically comment parts of my kernel out until I can isolate the line(s) of code that cause the error. Once you know the code or code style that is causing issues you can typically refactor it to be more compiler friendly.

    --- Quote End ---

    To be honest this is the best way to answer this question.

    When it comes to such compiler crashes, there is neither a fixed pattern to why it crashes crash, nor a fixed pattern as to how it can be fixed/avoided, and there are A LOT of such crashes. These problems should be fixed by Altera since nobody else has access to the compiler's source code, and you can always open a ticket with Altera and report the problem; however, by the time the issue is confirmed and then fixed (if they opt to fix it), it will probably take a couple of months which is not a viable waiting time for most people. At the end of the day, refactoring the code to bypass the crash is probably the fastest solution.