similar to: [LLVMdev] next

On Nov 16, 2009, at 1:43 PM, Dale Johannesen wrote: > > On Nov 14, 2009, at 3:16 PMPST, Howard Hinnant wrote: > >> In many places there is code that looks like: >> >> MBBI = next(MBBI); >> >> In C++0X there is a std::next that is likely to be in scope when these >> calls are made. And due to ADL the above call becomes ambiguous: >>

On Nov 14, 2009, at 3:16 PMPST, Howard Hinnant wrote: > In many places there is code that looks like: > > MBBI = next(MBBI); > > In C++0X there is a std::next that is likely to be in scope when these > calls are made. And due to ADL the above call becomes ambiguous: > llvm::next or std::next? > > I recommend: > > MBBI = llvm::next(MBBI); > > -Howard

On Nov 16, 2009, at 10:49 AMPST, Howard Hinnant wrote: > On Nov 16, 2009, at 1:43 PM, Dale Johannesen wrote: > >> >> On Nov 14, 2009, at 3:16 PMPST, Howard Hinnant wrote: >> >>> In many places there is code that looks like: >>> >>> MBBI = next(MBBI); >>> >>> In C++0X there is a std::next that is likely to be in scope when

Howard Hinnant wrote: > On Nov 16, 2009, at 1:43 PM, Dale Johannesen wrote: > > >> "next" is a popular name; if it breaks llvm, I'd expect this standards change to break a lot of existing code. Do you really want to do that? >> > > I'm happy to open an LWG issue for you on this subject. Here are directions on submitting an issue: > >

I am pretty sure the .cpp files always explicitly use "llvm" namespace. Look for: using namespace llvm; Is that sufficient? Evan On Nov 14, 2009, at 3:16 PM, Howard Hinnant wrote: > In many places there is code that looks like: > > MBBI = next(MBBI); > > In C++0X there is a std::next that is likely to be in scope when these > calls are made. And due to ADL

On Fri, Sep 28, 2012 at 6:45 PM, Howard Hinnant <hhinnant at apple.com> wrote: > On Sep 28, 2012, at 5:54 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > > Reduced testcase: > > > > template<typename T> struct A { typedef decltype(T() + 0) type; }; > > template<typename T> struct B { > > struct C { typedef typename

Sorry, always end up not replying to the list: The main issue with dealing with next this way is that people adding new uses of next will probably not be using c++0x and therefore won't know it's ambiguous and that it needs to be qualified. There are also two issues with rvalue references and the STL: 1. EquivalenceClasses, in the insert and findLeader functions, it uses map functions

On Feb 28, 2012, at 6:34 AM, Chandler Carruth wrote: > Howard, high-level feedback from you would be particularly appreciated as I would love to contribute this to libc++ when the time is right. Does the enclosed implementation implement this part of N3333: http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2012/n3333.html#per.process.seed ? That to me seems like potentially the most

On Dec 3, 2009, at 5:24 AM, Ahmed Charles wrote: > Sorry, always end up not replying to the list: > > The main issue with dealing with next this way is that people adding new uses of next will probably not be using c++0x and therefore won't know it's ambiguous and that it needs to be qualified. True. But when this code is compiled under C++0X you get an easy to diagnose, easy

On Sep 28, 2012, at 10:18 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Fri, Sep 28, 2012 at 6:45 PM, Howard Hinnant <hhinnant at apple.com> wrote: > On Sep 28, 2012, at 5:54 PM, Richard Smith <richard at metafoo.co.uk> wrote: > > > Reduced testcase: > > > > template<typename T> struct A { typedef decltype(T() + 0) type; }; > >

On May 27, 2008, at 2:01 PM, Dale Johannesen wrote: > On May 27, 2008, at 1:40 PM, Mike Stump wrote: >> >> From n2461: >> >>> 8 The insert members shall not affect the validity of iterators and >>> references to the container, and the erase members shall invalidate >>> only iterators and references to the erased elements. >> >> Pretty

On Sun, 15 Nov 2009 22:49:42 -0800, Evan Cheng <evan.cheng at apple.com> wrote: > I am pretty sure the .cpp files always explicitly use "llvm" namespace. > Look for: > using namespace llvm; > > Is that sufficient? > No. To prevent ADL from finding std::next, you need an explicitly qualified name at the call site. Sebastian

On Feb 14, 2014, at 1:09 PM, Howard Hinnant <hhinnant at apple.com> wrote: > Author: hhinnant > Date: Fri Feb 14 15:09:01 2014 > New Revision: 201432 > > URL: http://llvm.org/viewvc/llvm-project?rev=201432&view=rev > Log: Remove myself as owner of libc++ > > Modified: > llvm/trunk/CODE_OWNERS.TXT > > Modified: llvm/trunk/CODE_OWNERS.TXT > URL:

On Sep 28, 2012, at 5:54 PM, Richard Smith <richard at metafoo.co.uk> wrote: > Reduced testcase: > > template<typename T> struct A { typedef decltype(T() + 0) type; }; > template<typename T> struct B { > struct C { typedef typename A<C*>::type type; }; > typedef typename A<C*>::type type; > }; > B<int> b; > > ... produces ...

This seems a very natural approach but I probably am having a trouble with the iterator invalidation. However, looking at other peephole optimizers passes, I couldn't see how to do this: #define BUILD_INS(opcode, new_reg, i) \ BuildMI(*MBB, MBBI, MBBI->getDebugLoc(), TII->get(X86::opcode)) \ .addReg(X86::new_reg, kill).addImm(i) for

I made the change to the BuildMI() call. Again, I don't think that matters. #define BUILD_INS(opcode, new_reg, i) \ BuildMI(*MBB, OldMI, MBBI->getDebugLoc(), TII->get(X86::opcode)) \ .addReg(X86::new_reg, kill).addImm(i) I didn't completely understand your other proposed change: ​ for (MachineBasicBlock::iterator MBBI = MBB->begin();

Thanks for the information. I still don't know how do I partition registers into different classes from the virtual registers? For instance, I have the function who which iterates over the instructions, but I don't know how to write the function which returns the different register class. void RAOptimal::Gather(MachineFunction &Fn) { // Gather just iterates over the blocks,

Hi, I am writing an llvm pass wherein I require to iterate MachineBasicBlocks in reverse. The ilist reverse_iterator is not functioning as expected. Nor is the ilist iterator working in reverse (although -- operator is overloaded to do so). for (MachineFunction::iterator MBBI = mf_->end(), E = mf_->begin();MBBI != E; --MBBI) { MachineBasicBlock *MBB = MBBI;

Because I feel bad for giving a non-answer: An easy way to find if a virtual register is alive after the basic block is to While iterating over the virtual registers - Check to see if the virtual register's "next" value exists outside of the basic block. for instance: std::vector<unsigned> findLiveOut( MachineBasicBlock * mbb ) { std::vector<unsigned> liveout; for(

On Fri, Feb 14, 2014 at 1:29 PM, Howard Hinnant <hhinnant at apple.com> wrote: > On Feb 14, 2014, at 4:23 PM, Marshall Clow <mclow.lists at gmail.com> wrote: > >> On Feb 14, 2014, at 1:09 PM, Howard Hinnant <hhinnant at apple.com> wrote: >> >>> Author: hhinnant >>> Date: Fri Feb 14 15:09:01 2014 >>> New Revision: 201432 >>>