search for: conjury

everyone-- I notice that Llvm.llvm_handle_to_type is actually defined to create a type handle from a type, rather than vice versa as its name would imply. Should I send a patch to change the name of the function to reflect its type better, or should I just lump it? — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

...gcc] Error 2 Any tips that lead to the isolation of this issue will be graciously accepted. If I figure this out, I'll report back here what I'm doing wrong. If I don't, then I will probably bag on compiling libgcc2 for now and come back to it later. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

...then *that* isn't clear from the documentation. So, what is the correct form? Are parameter attributes part of function types, or are they just qualifiers to the function arguments at call sites and function declarations? Thanks for any help you guys can provide. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

to me the name implies that it creates a handle to the type given, i guess if you look at it in context of the ocaml conversion functions some people may think otherwise. On Tue, Jan 26, 2010 at 6:49 PM, james woodyatt <jhw at conjury.org> wrote: > everyone-- > > I notice that Llvm.llvm_handle_to_type is actually defined to create a type > handle from a type, rather than vice versa as its name would imply. Should > I send a patch to change the name of the function to reflect its type > better, or should I...

On Mar 1, 2010, at 20:28, Eli Friedman wrote: > On Mon, Mar 1, 2010 at 8:20 PM, james woodyatt <jhw at conjury.org> wrote: >> I'm sorry to pester about this, but I was really hoping somebody could straighten me out about this. The Language Reference really does seem to be ambiguous about this, and I'm willing to compose a patch to fix it, but I need to know what the document should actuall...

On Mon, Mar 1, 2010 at 8:20 PM, james woodyatt <jhw at conjury.org> wrote: > On Mar 1, 2010, at 09:56, james woodyatt wrote: >> On Mar 1, 2010, at 04:43, Duncan Sands wrote: >>> >>> Where exactly?  I don't see it in the online version. >> >> See <http://llvm.org/docs/LangRef.html#t_function> and look at the s...

...quot; that return a > structure's subtypes. Anyone mind if I rename it to > "struct_element_types" so that the union and struct function are > similar? Again, knock yourself out. I can live with just about any compatibility breaking improvements. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

...I suppose I'll end up ripping off bcopy.s for ARM from the obvious place, and assembling that for use in the final link. That should solve my problem. I mention it here because it was a little surprising when my memcpy() didn't show up where I expected. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

...34,15 @@ | Nest | Readnone | Readonly + | Noinline + | Alwaysinline + | Optforsize + | Stackprotect + | Stackprotectreq + | Nocapture + | Noredzone + | Noimplicitfloat + | Naked end (** The predicate for an integer comparison ([icmp]) instruction. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

...t by bundling LLVM with the GHC sources, they'll be able to remove a whole passle of Perl and GCC-related crawling horrors. They're hoping to get some performance improvements out of the migration. Let us all now give a warm welcome to our new Haskell comrades! — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

...my confusion over the issue. If parameter attributes aren't included in function types, then I'd like to know how to call a function through a pointer of the type in the example above. I must be failing still to comprehend an important concept in the language. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

...e > + | Optforsize > + | Stackprotect > + | Stackprotectreq > + | Nocapture > + | Noredzone > + | Noimplicitfloat > + | Naked > end > > (** The predicate for an integer comparison ([icmp]) instruction. > > > > > — > j h woodyatt <jhw at conjury.org> > http://jhw.vox.com/ > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...ies for [declare_qualified_global] and [define_qualified_global] that you've given the address space parameter the name [as], which is a reserved word in OCaml. The actual code doesn't use this name, which is why it compiles, but the OCamldoc output looks weird. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

...ember now. There is one thing I probably won't get around to doing myself until after the code freeze. (* Llvm_bitwriter *) val output_bitcode: out_channel -> Llvm.llmodule -> unit It would, of course, be awesome if you could get that into the 2.7 train. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

everyone-- Maybe I'm missing it, but I don't see how to apply parameter attributes to function return types in either the C-language or OCaml bindings. Can anybody help clue me in? Thanks. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/

...ons in the "Operations on parameters" parameters section actually seem to work only on the function arguments and not the return parameter. Is this intentional? What should I do if I need to get or set the return parameter attributes of a function from OCaml? — j h woodyatt <jhw at conjury.org> http://jhw.dreamwidth.org/

james woodyatt <jhw at conjury.org> writes: > p.s. The Mercurial subrepositories feature is loads better than git > submodules and it's built into the tool. But never mind that. Just go > with Git and don't look back. Nobody ever got fired for buying from > the market leader. I don't use submodules e...

...; bcopy.s for ARM from the obvious place, and assembling that for use in > the final link. That should solve my problem. > > I mention it here because it was a little surprising when my memcpy() > didn't show up where I expected. > > > — > j h woodyatt <jhw at conjury.org> > http://jhw.vox.com/ > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >

I've pretty much finished exposing all I wanted to llvm-c and the ocaml bindings for the soon to be released 2.7. Does anyone need any other functions exposed before the code freeze on the 7th?

On Apr 30, 2008, at 11:19 PM, james woodyatt wrote: >> $TMPFILE:66: Error: internal_relocation (type: OFFSET_IMM) not >> fixed up You need to run the compile with -save-temps and then look at the .s file. If you like it, it is an assembler bug. If you don't like it, it is a bug in the compiler. If you don't know if you like it, as your assembler vendor (binutils)