similar to: [LLVMdev] Warning in Clang

Displaying 20 results from an estimated 6000 matches similar to: "[LLVMdev] Warning in Clang"

2011 Feb 18
0
[LLVMdev] DIFactory
I didn't know DIFactory existed until you mentioned it just now. And if folks are adding brand new classes to LLVM, can we not follow the naming conventions in the developer guidelines? On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin <rengolin at systemcall.org>wrote: > Seems the last use of DIFactory in LLVM/Clang is in: > > clang/lib/CodeGen/CGDebugInfo.cpp to get the enums
2011 Mar 14
3
[LLVMdev] Warning in LLVM
When compiling LLVM on my Intel(R) Core(TM)2 Duo CPU P7450 running Ubuntu (gcc 4.4.5), I get this warning: /home/rengolin/workspace/llvm/rw/build/Release+Asserts/lib/libLLVMARMAsmParser.a(ARMAsmParser.o): In function `(anonymous namespace)::ARMAsmParser::ParseRegisterList(llvm::SmallVectorImpl<llvm::MCParsedAsmOperand*>&)': ARMAsmParser.cpp:(.text+0x4a05): warning: memset used with
2009 Nov 05
0
[LLVMdev] create dummy function
2009/11/5 Oleg Knut <oleg77 at gmail.com>: > Hello, > I have a simple question. How to create "dummy" function which will > have no functionality behind (return nothing and do nothing)? > Currently I'm trying to do this: > > llvm::Constant* c = Module.getOrInsertFunction("dummy", > FunctionThatNeedsToBeReplaced.getFunctionType()); >
2009 Nov 15
0
[LLVMdev] create dummy function
What exactly is M in that code you posted? Oleg Knut wrote: > > Thank you very much for you help, Renato! > > I read through paper you referred and also this document - > http://llvm.org/docs/tutorial/JITTutorial1.html > > Following these instructions to create successful function I run into > some problems: > 1) llvm::getGlobalContext() does not exists anymore?
2009 Nov 05
3
[LLVMdev] create dummy function
Thank you very much for you help, Renato! I read through paper you referred and also this document - http://llvm.org/docs/tutorial/JITTutorial1.html Following these instructions to create successful function I run into some problems: 1) llvm::getGlobalContext() does not exists anymore? "llvm/LLVMContext.h" too? 2) creating instance of IRBuilder don't require template (from tutorial
2010 Sep 26
2
[LLVMdev] LLVM Exception Handling
Ok, I see it. Works for me. On Sun, Sep 26, 2010 at 3:01 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 26 September 2010 22:11, Nathan Jeffords <blunted2night at gmail.com> > wrote: > > The "exception" value will *always* be i8*, it is not possible for it to > be > > anything different. > > In the end, this a minor parser detail and it
2010 Sep 21
0
[LLVMdev] IR type safety
On Tue, Sep 21, 2010 at 12:27 PM, Renato Golin <rengolin at systemcall.org> wrote: > On 21 September 2010 17:48, Devang Patel <dpatel at apple.com> wrote: >> In the combined llvm IR, @p3 and @p won't match as expected. > > Hi Devang, > > That's not quite what I was thinking... Maybe I explained badly... > > Imagine this: > > -- a.ll -- >
2010 Sep 21
0
[LLVMdev] IR type safety
This is a nominative vs. structural type system issue. You assume the type system to be nominative, while LLVM uses a structural one. In this type system Foo and Bar is the same type. There are various pros and cons for both systems. For LLVM it seems appropriate to use structural typing as it only uses types to calculate sizes, offsets and alignments. Btw arguably this is not a type safety
2010 Sep 07
4
[LLVMdev] Union type, is it really used or necessary?
Here's a suggestion - can we make the "union patch" (the inverse of the patch that removed unions) as a downloadable file so that people who are interested in finishing the work can do so? On Tue, Sep 7, 2010 at 7:55 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 7 September 2010 15:36, Anton Korobeynikov <anton at korobeynikov.info> > wrote: > >
2009 Aug 22
0
[LLVMdev] Having JIT resolve extern "C" functions declared in executible
I think you might have to provide an empty list if your function doesn't take parameters. Maybe using an irbuilder would help? -bw On Aug 22, 2009, at 2:13 PM, Renato Golin <rengolin at systemcall.org> wrote: > 2009/7/4 Albert Graef <Dr.Graef at t-online.de>: >> This is all I ever needed to interface to C functions using LLVM. >> It's >> really
2010 Sep 26
2
[LLVMdev] LLVM Exception Handling
On Sun, Sep 26, 2010 at 1:44 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 26 September 2010 20:13, Nathan Jeffords <blunted2night at gmail.com> > wrote: > > I believe the perceived problem with using eh.exception is that > > is disassociates the source of the value with the invoke instruction that > > generated it. As far as reusing the landing pad,
2010 Sep 07
0
[LLVMdev] More DIFactory questions - still stumped
If llvm compiler mis compiles a code then it is unlikely to be a bug in IRBuilder. Most likely it could be a bug in FE's use of IRBuilder or codegen/optimization bug. In either case IRBuilder won't save you. Same is true for DIFactory. It is a utility to construct MDNodes. It does not strictly enforce semantic correctness of debug info. (In fact, it is on my list somewhere to absorb
2010 Sep 07
2
[LLVMdev] More DIFactory questions - still stumped
On Tue, Sep 7, 2010 at 1:56 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 6 September 2010 01:05, Talin <viridia at gmail.com> wrote: > > DISubprogram CodeGenerator::genDISubprogram(const FunctionDefn * fn, > (...) > > false /* isDefinition */, > (...) > > Hi Talin, > > The only difference from what I'm doing is that I only
2010 Sep 06
2
[LLVMdev] More DIFactory questions - still stumped
On Sun, Sep 5, 2010 at 1:02 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 5 September 2010 19:32, Talin <viridia at gmail.com> wrote: > > I've carefully studied the source code of CGDebugInfo in clang as a > working > > example. One puzzlement is that there's a discrepancy between what the > > "source level debugging with LLVM" docs
2010 Sep 26
3
[LLVMdev] LLVM Exception Handling
On Sun, Sep 26, 2010 at 11:27 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 26 September 2010 18:56, Nathan Jeffords <blunted2night at gmail.com> > wrote: > > The syntax for the invoke instruction is a little misleading. %x is a > value > > that is being generated by the instruction, not passed to is. It is no > > different in that regard as to
2011 Feb 18
2
[LLVMdev] DIFactory
Seems the last use of DIFactory in LLVM/Clang is in: clang/lib/CodeGen/CGDebugInfo.cpp to get the enums llvm::DIFactory::OpDeref and llvm::DIFactory::OpPlus. Shouldn't this be moved to DIBuilder and remove the dependency completely? -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm
2009 Aug 25
0
[LLVMdev] Simple example
Hi all, Thanks to the help of you guys I finally got my simple example working. http://www.systemcall.org/rengolin/stuff/compiler/ It's still missing some language features (described on the page) and the optimization part (which I'll do next), but all in all, it's executing my simple example. ;) Thanks again for all the help, cheers, --renato Reclaim your digital rights,
2009 Sep 27
0
[LLVMdev] LLVM presentation
Hi all, I've created a small presentation about LLVM, why and how easy it is to use it. It's showing a few of the codegen basic blocks, plus optimization pass managers and JIT, with references to the LLVM documentation and the Kaleidoscope tutorial. My understanding of LLVM is far from comprehensive, so there might be some inaccuracies (please, let me know). Nevertheless, if you find
2011 Feb 18
4
[LLVMdev] DIFactory
Sorry, I meant DIBuilder. On Fri, Feb 18, 2011 at 1:32 PM, Talin <viridia at gmail.com> wrote: > I didn't know DIFactory existed until you mentioned it just now. > > And if folks are adding brand new classes to LLVM, can we not follow the > naming conventions in the developer guidelines? > > On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin <rengolin at
2009 Nov 30
1
[LLVMdev] JVM Backend
> If you apply that as a patch now, everyone else will have to maintain > it when they do their unrelated changes, increasing the cost of the > project's maintenance. I welcome your code (have been wondering about > it recently too), but I think that you should keep it as a separate > project for now. Once it's at least complete, I'm sure people will be > happy to