search for: owningptr

...sands of them - and I'm not sure what I did to cause them or how to solve them: ld: warning llvm::MemoryBuffer::getBufferStart() const has different visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) ld: warning llvm::OwningPtr<llvm::MemoryBuffer>::OwningPtr(llvm::MemoryBuffer*)has different visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) ld: warning llvm::OwningPtr<llvm::MemoryBuffer>::OwningPtr(llvm::MemoryBuffer*)has different...

...t; not sure what I did to cause them or how to solve them: > > ld: warning llvm::MemoryBuffer::getBufferStart() const has different > visibility (1) in /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and > (2) in /usr/local/lib/libLLVMSupport.a(CommandLine.o) > ld: warning > llvm::OwningPtr<llvm::MemoryBuffer>::OwningPtr(llvm::MemoryBuffer*)has > different visibility (1) in > /usr/local/lib/libLLVMSupport.a(MemoryBuffer.o) and (2) in > /usr/local/lib/libLLVMSupport.a(CommandLine.o) > ld: warning > llvm::OwningPtr<llvm::MemoryBuffer>::OwningPtr(llvm::MemoryBu...

...ust pass the pointer, > not a 'const std::unique_ptr &' or anything.) > > Jordan > > > On Jul 17, 2014, at 16:21 , David Blaikie <dblaikie at gmail.com> wrote: > > > There seems to be some uncertainty about the use of smart pointers > > (previously OwningPtr, now std::unique_ptr and std::shared_ptr > > predominantly) in the LLVM project as a whole, so here's a thread to > > discuss/clarify/etc the project preferences/direction with regard to > > smart pointer usage. > > > > For some context, see discussions in LLVM r21...

There seems to be some uncertainty about the use of smart pointers (previously OwningPtr, now std::unique_ptr and std::shared_ptr predominantly) in the LLVM project as a whole, so here's a thread to discuss/clarify/etc the project preferences/direction with regard to smart pointer usage. For some context, see discussions in LLVM r212403 and Clang r213307. The basic question here...

...th C and Objective-C and find C++ syntax absolutely bewildering. Kind regards, Aidan Steele int main (int argc, const char *argv[]) { LLVMInitializeARMTargetInfo(); LLVMInitializeARMTargetMC(); LLVMInitializeARMAsmParser(); LLVMInitializeARMDisassembler(); const llvm::Target Target; llvm::OwningPtr<const llvm::MCSubtargetInfo> STI(Target.createMCSubtargetInfo("", "", "")); llvm::OwningPtr<const llvm::MCDisassembler> disassembler(Target.createMCDisassembler(*STI)); llvm::OwningPtr<llvm::MemoryBuffer> Buffer; llvm::MemoryBuffer::getFile(llvm::...

...tch -p0". > > +  // Make sure the code model is set. > +  setCodeModelForStatic(); > > For the JIT, this should be setCodeModelForJIT; it makes a difference > on, for example, x86-64.  I'd also suggest changing the name of the > method appropriately. > > -  llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS)); > -  if (!Writer) > -    report_fatal_error("unable to create object writer!"); > +  MCObjectWriter *Writer = Writer_; > +  if (Writer == 0) { > +      Writer = getBackend().createObjectWriter(OS); > +  ...

...c.h" #include "clang/Frontend/TextDiagnosticPrinter.h" #include "llvm/DerivedTypes.h" #include "llvm/Support/TypeBuilder.h" #include "llvm/LLVMContext.h" #include "llvm/Module.h" #include "llvm/Config/config.h" #include "llvm/ADT/OwningPtr.h" #include "llvm/ADT/SmallString.h" #include "llvm/Config/config.h" #include "llvm/ExecutionEngine/ExecutionEngine.h" #include "llvm/Support/ManagedStatic.h" #include "llvm/Support/raw_ostream.h" #include "llvm/System/Host.h" #includ...

...+ // Make sure the code model is set. + setCodeModelForJIT(); + + return false; // success! +} + -void MCAssembler::Finish() { +void MCAssembler::Finish(MCObjectWriter *Writer_) { Why two variables Writer_ and Writer? I don't know of any rules against modifying parameters. ... - llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS)); - if (!Writer) - report_fatal_error("unable to create object writer!"); + + llvm::OwningPtr<MCObjectWriter> OwnWriter(0); + MCObjectWriter *Writer = Writer_; + if (Writer == 0) { + //no custom Writer_ : cre...

...th C and Objective-C and find C++ syntax absolutely bewildering. Kind regards, Aidan Steele int main (int argc, const char *argv[]) { LLVMInitializeARMTargetInfo(); LLVMInitializeARMTargetMC(); LLVMInitializeARMAsmParser(); LLVMInitializeARMDisassembler(); const llvm::Target Target; llvm::OwningPtr<const llvm::MCSubtargetInfo> STI(Target.createMCSubtargetInfo("", "", "")); llvm::OwningPtr<const llvm::MCDisassembler> disassembler(Target.createMCDisassembler(*STI)); llvm::OwningPtr<llvm::MemoryBuffer> Buffer; llvm::MemoryBuffer::getFile(llvm::...

...LVM > compliant. Apply it with "patch -p0". + // Make sure the code model is set. + setCodeModelForStatic(); For the JIT, this should be setCodeModelForJIT; it makes a difference on, for example, x86-64. I'd also suggest changing the name of the method appropriately. - llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS)); - if (!Writer) - report_fatal_error("unable to create object writer!"); + MCObjectWriter *Writer = Writer_; + if (Writer == 0) { + Writer = getBackend().createObjectWriter(OS); + if (!Writer) + rep...

...> > Kind regards, > Aidan Steele > > int main (int argc, const char *argv[]) > { > LLVMInitializeARMTargetInfo(); > LLVMInitializeARMTargetMC(); > LLVMInitializeARMAsmParser(); > LLVMInitializeARMDisassembler(); > > const llvm::Target Target; > > llvm::OwningPtr<const llvm::MCSubtargetInfo> > STI(Target.createMCSubtargetInfo("", "", "")); > llvm::OwningPtr<const llvm::MCDisassembler> > disassembler(Target.createMCDisassembler(*STI)); > > llvm::OwningPtr<llvm::MemoryBuffer> Buffer; > llvm::M...

I tried what you said, now I get: LLVM ERROR: Program used external function 'yipee' which could not be resolved! Stack dump: 0. Running pass 'X86 Machine Code Emitter' on function '@main' did not even get as far as a breakpoint. Óscar Fuentes wrote: > > gafferuk <gafferuk at gmail.com> writes: > >> Im confused. The function i wish to call is

gafferuk <gafferuk at gmail.com> writes: > Im confused. The function i wish to call is a return type of int. > Im calling it with int dd = yipee(1); > > What's wrong? Declare the function: int yipee(int); int main() { int dd = yipee(1); return 0; } If that still crashes, put a breakpoint on `yipee' and see if the execution gets there, if the argument is

...r anything.) > >> > >> Jordan > >> > >> > >> On Jul 17, 2014, at 16:21 , David Blaikie <dblaikie at gmail.com> wrote: > >> > >> > There seems to be some uncertainty about the use of smart pointers > >> > (previously OwningPtr, now std::unique_ptr and std::shared_ptr > >> > predominantly) in the LLVM project as a whole, so here's a thread to > >> > discuss/clarify/etc the project preferences/direction with regard to > >> > smart pointer usage. > >> > > >> >...

...quot; #include "clang/Driver/Tool.h" #include "clang/Frontend/CompilerInstance.h" #include "clang/Frontend/CompilerInvocation.h" #include "clang/Frontend/FrontendDiagnostic.h" #include "clang/Frontend/TextDiagnosticPrinter.h" #include "llvm/ADT/OwningPtr.h" #include "llvm/ADT/SmallString.h" #include "llvm/ExecutionEngine/ExecutionEngine.h" #include "llvm/ExecutionEngine/JIT.h" #include "llvm/IR/Module.h" #include "llvm/Support/Host.h" #include "llvm/Support/ManagedStatic.h" #include &...

...s/MipsTargetMachine.h b/lib/Target/Mips/MipsTargetMachine.h index 7e5f192..ee55708 100644 --- a/lib/Target/Mips/MipsTargetMachine.h +++ b/lib/Target/Mips/MipsTargetMachine.h @@ -21,6 +21,8 @@ #include "MipsSelectionDAGInfo.h" #include "MipsSubtarget.h" #include "llvm/ADT/OwningPtr.h" +#include "llvm/CodeGen/Passes.h" +#include "llvm/CodeGen/SelectionDAGISel.h" #include "llvm/IR/DataLayout.h" #include "llvm/Target/TargetFrameLowering.h" #include "llvm/Target/TargetMachine.h" @@ -35,6 +37,12 @@ class MipsTargetMachine :...

...type { float, float, float, float, float, i32 }. In the second module->dump, %struct.cmd becomes %struct.cmd0. my code is simplified like this. int main() { llvm::LLVMContext &llvmCtx = llvm::getGlobalContext(); string ErrMsg; string filename = "wrapper.bc"; llvm::OwningPtr<llvm::MemoryBuffer> File; if (llvm::MemoryBuffer::getFileOrSTDIN(filename, File)) { assert(0); } llvm::MemoryBuffer * buffer = File.take(); { llvm::OwningPtr<llvm::Module> module(llvm::ParseBitcodeFile(buffer, llvmCtx, &ErrMsg)); module->...

...> +#define LLVM_SUPPORT_FILEOUTPUTBUFFER_H > + > +#include "llvm/Support/DataTypes.h" > +#include "llvm/ADT/StringRef.h" > +#include "llvm/ADT/SmallString.h" > + > +namespace llvm { > + > +class error_code; > +template<class T> class OwningPtr; > + > +/// FileOutputBuffer - This interface provides simple way to create an in-memory > +/// buffer which will be written to a file. During the lifetime of these > +/// objects, the content or existence of the specified file is undefined. That > +/// is, creating an OutputBuffer f...

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for

...gt; + > +  return false; // success! > +} > + > > -void MCAssembler::Finish() { > +void MCAssembler::Finish(MCObjectWriter *Writer_) { > > Why two variables Writer_ and Writer?  I don't know of any rules against > modifying parameters. > > ... > > -  llvm::OwningPtr<MCObjectWriter> Writer(getBackend().createObjectWriter(OS)); > -  if (!Writer) > -    report_fatal_error("unable to create object writer!"); > + > +  llvm::OwningPtr<MCObjectWriter> OwnWriter(0); > +  MCObjectWriter *Writer = Writer_; > +  if (Writer == 0) {...