search for: makearrayref

...M.begin(), E = M.end(); F != E; ++F) { Function *fun = dyn_cast<Function>(F); Value *Opts[1]; BasicBlock &bb = F->getEntryBlock(), *newBB; newBB = BasicBlock::Create(M.getContext(), "initfunc", F, &bb); CallInst::Create(func, makeArrayRef(Opts, 1) , "", newBB); BranchInst::Create(&bb, newBB); } } The pass compiles fine but when I use 'opt' to instrument a simple C program then I get the following exception: $ opt -o a.bc -load /data/llvm3.1/Release+Asserts/lib/Dat.so -MyPass < malloc.bc opt: In...

...> Function *fun = dyn_cast<Function>(F); > > Value *Opts[1]; > > BasicBlock &bb = F->getEntryBlock(), *newBB; > > newBB = BasicBlock::Create(M.getContext(), "initfunc", F, &bb); > > *CallInst::Create(func, makeArrayRef(Opts, 1) , "", newBB);* But here you pass it an argument. Note you don't need makeArrayRef, you can just pass Opts. It will be magically turned into an ArrayRef. Ciao, Duncan. PS: Opts[1] is not initialized, this will cause problems! > > BranchInst::Create(&...

We should make LLD to be able to build with GCC even if GCC is a bit buggy. So you wrote that it's no longer build because of the recent change of makeArrayRef removal? I think it's my change (r196475). Can you confirm that you can build if you revert that change? If it has caused the build with GCC to break, we should roll it back. On Sun, Dec 8, 2013 at 3:45 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > Yup, I can confirm that. T...

...>> >> Nope - since the temporary is a subexpression - not the thing being declared. >> > > >>>>>>> We could move this ctor into a factory function (and/or just make the >>>>>>> CTor >>>>>>> private and friend the makeArrayRef helper for this case) to make it >>>>>>> more >>>>>>> obvious/easier to find bad call sites. But it would be helpful to >>>>>>> have >>>>>>> the >>>>>>> context of the prior discussion to contin...

...:ID CallConv, + const X86Subtarget &Subtarget) { + assert(Subtarget.is64Bit()); + + if (Subtarget.isCallingConvWin64(CallConv)) { + static const MCPhysReg GPR64ArgRegsWin64[] = { + X86::RCX, X86::RDX, X86::R8, X86::R9 + }; + return makeArrayRef(std::begin(GPR64ArgRegsWin64), std::end(GPR64ArgRegsWin64)); + } + + static const MCPhysReg GPR64ArgRegs64Bit[] = { + X86::RDI, X86::RSI, X86::RDX, X86::RCX, X86::R8, X86::R9 + }; + return makeArrayRef(std::begin(GPR64ArgRegs64Bit), std::end(GPR64ArgRegs64Bit)); +} + + /// emitPrologue - Pu...

Analyzing why GCC failed to build LLVM recently, one root cause lies in definition of ArrayRef: // ArrayRef.h: ArrayRef(const T &OneElt) : Data(&OneElt), Length(1) {} Here address of const reference is taken and stored to an object. It is believed that live range of const reference is only at the function call site, escaping of its address to an object with a longer live range is invalid.

...; >> > greater >> >> > suspicion, the same way we do for twine, but I'm not sure. >> >> > >> >> > We could move this ctor into a factory function (and/or just make the >> >> > CTor >> >> > private and friend the makeArrayRef helper for this case) to make it >> >> > more >> >> > obvious/easier to find bad call sites. But it would be helpful to >> >> > have >> >> > the >> >> > context of the prior discussion to continue from there. >> >&g...

...ime it built, so I suppose it is revision 196475 that is the problem. -- Mikael 2013/12/9 Rui Ueyama <ruiu at google.com> > We should make LLD to be able to build with GCC even if GCC is a bit > buggy. So you wrote that it's no longer build because of the recent change > of makeArrayRef removal? I think it's my change (r196475). > > Can you confirm that you can build if you revert that change? If it has > caused the build with GCC to break, we should roll it back. > > > On Sun, Dec 8, 2013 at 3:45 PM, Mikael Lyngvig <mikael at lyngvig.org> wrote: > &...

...ggested we might just want to make a > practice of treating named/local (not parameter) ArrayRef's with greater > suspicion, the same way we do for twine, but I'm not sure. > > We could move this ctor into a factory function (and/or just make the CTor > private and friend the makeArrayRef helper for this case) to make it more > obvious/easier to find bad call sites. But it would be helpful to have the > context of the prior discussion to continue from there. > > On Aug 19, 2014 11:18 PM, "Joey Ye" <joey.ye.cc at gmail.com> wrote: > > Analyzing w...

...stant *dhashInit[] = {filenmConst, intConst}; Constant *dhashConst = ConstantStruct::get(dhashTy, dhashInit); Constant* htabInitArr[2]; htabInitArr[0] = dhashConst; htabInitArr[1] = dhashConst; ArrayType *htabTy = ArrayType::get(dhashTy, 2); Constant *htabInit = ConstantArray::get(htabTy, makeArrayRef(htabInitArr,2)); GlobalVariable *htabConst = new GlobalVariable(M, htabInit->getType(), false, GlobalVariable::ExternalLinkage, htabInit, "htab"); Here is the error message: opt: /home/chaitra/llvm-5-src/lib/IR/Constants.cpp:879: ll...

...of treating named/local (not parameter) ArrayRef's with greater >> > suspicion, the same way we do for twine, but I'm not sure. >> > >> > We could move this ctor into a factory function (and/or just make the >> > CTor >> > private and friend the makeArrayRef helper for this case) to make it >> > more >> > obvious/easier to find bad call sites. But it would be helpful to have >> > the >> > context of the prior discussion to continue from there. >> > >> > On Aug 19, 2014 11:18 PM, "Joey Ye"...

...our gc-root tracking algorithm implementation if desired (I also plan to be at the llvm-devmtg). It'd be great to know if there's opportunities for collaboration, or at least sharing insights and experiences! llvm.experimental.gc.ptrtoint: dropgcroot_type = FunctionType::get(PtrIntTy, makeArrayRef(PointerType::get(AddressSpace::Derived)), false); dropgcroot_func = Function::Create(dropgcroot_type, Function::ExternalLinkage, "julia.pointer_from_objref"); dropgcroot_func->addFnAttr(Attribute::ReadNone); dropgcroot_func->addFnAttr(Attribute::NoUnwind); declare v...

Yup, I can confirm that. Then the question is if LLD shouldn't compile with GNU, even if GNU is buggy. Personally, I think it is worth a lot to be able to build with GCC, but I don't know how the LLD developers feel about that. -- Mikael 2013/12/7 Simon Atanasyan <simon at atanasyan.com> > On Sat, Dec 7, 2013 at 10:00 PM, Duncan P. N. Exon Smith > <dexonsmith at

On Sat, Dec 7, 2013 at 10:00 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > On 2013 Dec 7, at 04:23, Mikael Lyngvig <mikael at lyngvig.org> wrote: > >> I am using the -std=c++11 flag to GCC. > > I didn’t even look at your errors, but my understanding is that -std=gnu++11 is more used (and much better tested) than -std=c++11. Any chance that fixes it

...: *** [all] Error 2 It seems to me that there is a possible incompatibility between GCC v4.8.2 and Clang because the Clang builders did the build without errors. I am using the -std=c++11 flag to GCC. Any advice on how to proceed? The problem seems related to a recent change that eliminated the makeArrayRef() call in that very module. Perhaps GCC and Clang differ in opinion on when to do automatic casts are not? -- Mikael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131207/6b3e4cbc/attachment.html>

...th(1) {} > > /// Construct an ArrayRef from a pointer and length. > > and rebuilding LLVM and Clang gives me: > > $ ninja 2>&1 | grep -e Wdeprecated-declarations | wc -l > 6083 Uniqued? I imagine a few are in headers. > > This includes forwards from the `makeArrayRef()` helper.

Thank you very much. The code to initialize h1 to non-zero values was what I was looking for. It's almost working except for a type mismatch wrt dlist* llist field of h1. dlist static_lst[10] = { {1, 5, NULL}, ... }; dhash h1[10] = {{"myfile.txt", static_lst}, ... }; Along the lines of the code you had sent, I created a GlobalVariable* llist of type [10 x %struct.dlist]* for the

Hi All, I'm working on a project converting Dart to llvm. Dart uses a relocating GC but additionally uses pointer tagging. The first bit of a pointer is a tag. For integers a '0' bit is used and for pointers to objects a '1' bit is used. V8 apparently uses a similar technique. Generated code may need to check which bit is used when this information isn't statically known.

...previous discussion I suggested we might just want to make a practice of treating named/local (not parameter) ArrayRef's with greater suspicion, the same way we do for twine, but I'm not sure. We could move this ctor into a factory function (and/or just make the CTor private and friend the makeArrayRef helper for this case) to make it more obvious/easier to find bad call sites. But it would be helpful to have the context of the prior discussion to continue from there. On Aug 19, 2014 11:18 PM, "Joey Ye" <joey.ye.cc at gmail.com> wrote: > Analyzing why GCC failed to build LLVM...

...ggested we might just want to make a > practice of treating named/local (not parameter) ArrayRef's with greater > suspicion, the same way we do for twine, but I'm not sure. > > We could move this ctor into a factory function (and/or just make the CTor > private and friend the makeArrayRef helper for this case) to make it more > obvious/easier to find bad call sites. But it would be helpful to have the > context of the prior discussion to continue from there. > On Aug 19, 2014 11:18 PM, "Joey Ye" <joey.ye.cc at gmail.com> wrote: > > > Analyzing why G...