search for: llvmgetattribut

...09 at 2:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > My front-end is sync'd with the trunk now, and working well, but it > required some additional functions exposed in the C bindings.  I > hereby submit them for review and approval for inclusion in the trunk. > LLVMGetAttribute had a bug in it. Here's the revised version of the patch -------------- next part -------------- A non-text attachment was scrubbed... Name: cbindings.patch Type: text/x-patch Size: 7271 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091006/91de8d57/...

My front-end is sync'd with the trunk now, and working well, but it required some additional functions exposed in the C bindings. I hereby submit them for review and approval for inclusion in the trunk. -------------- next part -------------- A non-text attachment was scrubbed... Name: cbindings.patch Type: application/octet-stream Size: 7269 bytes Desc: not available URL:

...will be extending this class to encompass many other attributes. The changes pose one problem, however. The C-API still uses the old data representation for passing along the Attributes class. In particular, these two functions: LLVMAttribute LLVMGetFunctionAttr(LLVMValueRef Fn); LLVMAttribute LLVMGetAttribute(LLVMValueRef Arg); return the LLVMAttribute, which is an enum that happens to be the internal bit representation of the Attributes object. This is bad for several reasons, not the least of which is that it's completely inextensible (e.g., we don't have room for LLVMAddressSafety). I woul...

On Tue, Oct 6, 2009 at 5:47 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > > LLVMGetAttribute had a bug in it.  Here's the revised version of the patch Hi Kenneth! I wouldn't say that I'm the best reviewer, but I've been doing some work with the c bindings recently so hopefully I have some idea of what I'm talking about :) Comments are inlined: +/** See the llvm::Us...

...kennethuil at gmail.com> wrote: >> My front-end is sync'd with the trunk now, and working well, but it >> required some additional functions exposed in the C bindings. I >> hereby submit them for review and approval for inclusion in the >> trunk. >> > > LLVMGetAttribute had a bug in it. Here's the revised version of the > patch Hi Kenneth, Thanks for working on this. I have some additional comments: +/** See the llvm::Use class. */ +typedef struct LLVMOpaqueUse *LLVMUseRef; My understanding is that this actually conceptually corresponds to use_i...

...class to encompass many other attributes. > > The changes pose one problem, however. The C-API still uses the old data representation for passing along the Attributes class. In particular, these two functions: > > LLVMAttribute LLVMGetFunctionAttr(LLVMValueRef Fn); > LLVMAttribute LLVMGetAttribute(LLVMValueRef Arg); > > return the LLVMAttribute, which is an enum that happens to be the internal bit representation of the Attributes object. This is bad for several reasons, not the least of which is that it's completely inextensible (e.g., we don't have room for LLVMAddressSafety)...

...u, Oct 8, 2009 at 2:39 AM, Erick Tryzelaar <idadesub at users.sourceforge.net> wrote: > On Tue, Oct 6, 2009 at 5:47 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >> On Tue, Oct 6, 2009 at 2:13 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: >> >> LLVMGetAttribute had a bug in it.  Here's the revised version of the patch > > Hi Kenneth! > > I wouldn't say that I'm the best reviewer, but I've been doing some > work with the c bindings recently so hopefully I have some idea of > what I'm talking about :) Comments are inli...