similar to: [LLVMdev] ilist::getPrevNode asserts on list head

I may be mistaken as I just took a quick look, but in ilist_node the function "getPrevNode()" actually calls a method on the previous node: NodeTy *getPrevNode() { NodeTy *Prev = this->getPrev(); // Check for sentinel. if (!Prev->getNext()) return 0; return Prev; } http://llvm.org/docs/doxygen/html/ilist__node_8h_source.html#l00058 Try checking if

Hi All, I have just started using LLVM . i am facing a issue while using ilist container. Here is a struct with ilist container as its one element. typedef ilist<Instruction *> InstListType; struct list_node { int Impact; InstListType InstList; }; list_node

getPrevNode<http://llvm.org/docs/doxygen/html/classllvm_1_1ilist__node.html#a77b897207ef0a1ae95c404695aed9a4b>() Get the previous node, or 0 for the list head. I don't see any method like hasPrevNode. It can be a weird problem because "current->getPrevNode()" is indicating to "current" itself (the problem appears for the BB with only one element)? On Thu, Dec

I solved by checking if(BB->size()>1) Thank you all for the help ! Now debugging the next segfault. On Thu, Dec 20, 2012 at 12:59 PM, Alexandru Ionut Diaconescu < alexandruionutdiaconescu at gmail.com> wrote: > getPrevNode<http://llvm.org/docs/doxygen/html/classllvm_1_1ilist__node.html#a77b897207ef0a1ae95c404695aed9a4b>() > Get the previous node, or 0 for the list

Hello John, I was following your procedures and I isolated the problem. The problem are represented by the basic blocks with only one element. for (Function::iterator II = F.begin(), EE = F.end(); II != EE; ++II, ++ii) { BasicBlock* BB=II; if (BB->getTerminator()) { Instruction* current = BB->getTerminator(); Instruction* previous;

Hi all, I stumbled over a problem in ilist_node::getPrevNode(). It crashes when invoked for the first element in a list. It's because the Prev pointer of a first list element does not point to the sentinel but is just null. First question: Is this really a bug or am I doing something wrong? Second question: If it is a bug, what should be the correct behaviour? Either change insert() to let

Hello, Thank you for your answer. If I want to use then I have error: ‘NodeTy* llvm::ilist_half_node<NodeTy>::getPrev() [with NodeTy = llvm::Instruction]’ is protected error: ‘llvm::ilist_half_node<llvm::Instruction>’ is not an accessible base of ‘llvm::Instruction’ Do you know any other method to access the previous instruction of a terminator instruction? PS: back() is not an

I've been digging into some undefined behaviour stemming from how ilist is typically configured. r247937, r247944, and r247978 caused a UBSan failure to start firing on our Green Dragon bots, and after an IRC conversation between David and Nick and Mehdi, we added a blacklist: -- $echo "src:$WORKSPACE/llvm/include/llvm/CodeGen/MachineFunction.h" >> sanitize.blacklist --

I get the following error when I try to run arm lli on QEMU: lli: llvm-arm/src/llvm/include/llvm/ADT/ilist.h:197: typename bidirectional_iterator<NodeTy, int>::reference llvm::ilist_iterator<NodeTy>::operator*() const [with NodeTy = llvm::RecyclerStruct]: Assertion `Traits::getNext(NodePtr) != 0 && "Dereferencing end()!"' failed. 0 lli 0x006abbfc Stack dump: 0.

hannibal hannibal wrote: > I get the following error when I try to run arm lli on QEMU: > > lli: llvm-arm/src/llvm/include/llvm/ADT/ilist.h:197: typename bidirectional_iterator<NodeTy, int>::reference llvm::ilist_iterator<NodeTy>::operator*() const [with NodeTy = llvm::RecyclerStruct]: Assertion `Traits::getNext(NodePtr) != 0 && "Dereferencing end()!"'

AAAH! I see you are still at 2.5. Then this patch (the fix) is relevant for you: <http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/ ilist.h?r1=66061&r2=68785&diff_format=h> Cheers, Gabor On 27 Sep., 05:45, hc2... at columbia.edu wrote: > Dear developers: >      When I am doing basicblock pass, I meet a bug: there is an   > iterator "I" in

On 27 Sep., 05:45, hc2... at columbia.edu wrote: > Dear developers: >      When I am doing basicblock pass, I meet a bug: there is an   > iterator "I" in a basicblock, and it is not pointing to the first   > instruction in this basicblock. However, "I--;" will fail by an   > assertion. Hi hc! are you on SVN trunk? Cheers, Gabor > > The basic block

I am using LLVM 2.6 and I have a question on the use of the BasicBlock::iterator to hoist loop invariant instructions to the loop preheader. When I process the instructions backward as shown in the following code, I got the following error right after the "hoist(I)" is done. Can anyone advise whether I am misusing BasicBlock::iterator? /opt/llvms/src/llvm_26/

Quoting Gabor Greif <ggreif at gmail.com>: Hi Gabor, I can not open the link, can you send again? > AAAH! > > I see you are still at 2.5. Then this patch (the fix) > is relevant for you: > > <http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/ > ilist.h?r1=66061&r2=68785&diff_format=h> > > Cheers, > > Gabor > > >

Dear developers: When I am doing basicblock pass, I meet a bug: there is an iterator "I" in a basicblock, and it is not pointing to the first instruction in this basicblock. However, "I--;" will fail by an assertion. The basic block ("I" is pointing to the second instruction) in test.ll: bb: ; preds = %bb1 %1 = call i32 (i8*, ...)* @printf(i8* noalias

Hi all, I am in the process of developing a installer utility for ARM target which can compile any source files to ARM native executable. This installer utility should be present on target itself (whether this is feasible or not?). For achieving this i compiled llvm with clang for target. I copied the binaries to target and when it tried to compile a sample c code i am getting the following

Thanks Antont and Gabor.. I will use the iterator instead.. On 5/11/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: > Hello, Ferad. > > > I switched to the upcoming version 2.0 branch and porting my code from > > 1.9. Thanks there is not a lot to do. I found that > > Instruction::getNext and Instruction::getPrev are private. Is this > > intentional? >

Hi, I switched to the upcoming version 2.0 branch and porting my code from 1.9. Thanks there is not a lot to do. I found that Instruction::getNext and Instruction::getPrev are private. Is this intentional? If yes, what would you recommend instead using them? Thanks, Ferad

"Duncan P. N. Exon Smith via llvm-dev" <llvm-dev at lists.llvm.org> writes: >> On 2015-Oct-20, at 11:23, Reid Kleckner <rnk at google.com> wrote: >> >> I think the implicit iterator conversions are much less important >> now that we have range based for loops, but I still like having >> them. > > IMO, if a developer has an ilist iterator

Dear all, The below has been tested quite thoroughly by now, including performance-testing by the way of using a modified compiler that triggers the below while compiling at least an old part of LLVM ["Function.cpp"] and sorting a symbol table with >7000 global variables. Unfortunately, the optimization I have been working on for which I _thought_ I needed the ability to sort a