similar to: [LLVMdev] git Status

On Aug 18, 2011, at 10:57 AM, David Greene wrote: > > Did the project ever come to a decision about making a transition to > git? I'm trying to do some longer-term planning and it would be helpful > to know what the roadmap is. Me too. I've been catching up on the thread from a couple weeks ago, and I didn't see any clear conclusion. I have some comments about the

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 enough to be a good juge, but my understanding is that Git's

On Aug 19, 2011, at 2:36 PM, Talin wrote: > The Python language recently migrated from SVN to Mercurial as their version control system. As part of this effort, a detailed migration plan was written: > > http://www.python.org/dev/peps/pep-0385/ Hi guys, Just to be absolutely clear here, Mercurial is not being considered. -Chris -------------- next part -------------- An HTML

The Python language recently migrated from SVN to Mercurial as their version control system. As part of this effort, a detailed migration plan was written: http://www.python.org/dev/peps/pep-0385/ Now, I'm not proposing that we favor using Mercurial over Git*. But I would suggest that perhaps you could use the Python migration plan as a template for LLVM's migration. (*I use both

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/

everyone-- I'm trying to build LLVM-GCC as a cross-compiler for a new target. I've successfully patched binutils, the FSF GCC, LLVM and Clang to build for this new target-- they work fine, but the LLVM-gcc build is failing for me. All my llvm.org sources are tracking the Subversion trunk, but my problem is probably not related to any ongoing churn there. I'm doing something

everyone-- Is it my imagination, or is there no way in LLVM 2.8 (or current trunk) to use the facilities defined in <llvm-c/Core.h> to get or set the optional return parameter attribute on a function value? All the functions in the "Operations on parameters" parameters section actually seem to work only on the function arguments and not the return parameter. Is this intentional?

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 second example: > > float (i16 signext, i32 *) * > > Pointer to a function that takes an i16 that should be sign extended

everyone-- File this under Advocacy. See this thread <http://www.haskell.org/pipermail/glasgow-haskell-users/2010-February/018425.html> for more information, but the short summary is that they're deprecating their old "compile to GCC" backend in favor of David Terei's new LLVM backend. They're still planning for their C-- backend to be the primary backend for native

everyone-- I don't know whether this is a bug or not. I'm trying to bootstrap an embedded application and using LLVM tools to generate the assembly code, which I then assemble and link with traditional tools. The bootstrap loader, of course, runs in a very limited environment, and I have to roll my own memcpy() function for it, i.e. there is no kernel, nothing at all, this stuff

On Feb 18, 2010, at 12:51, Erick Tryzelaar wrote: > > I'm in the process of finishing up the ocaml llvm bindings, and I had > some last minute questions before we code freeze: > > 1. What version of ocaml is everyone using, and how old of an ocaml > version do you need to support? Still using OCaml 3.11.1, but will but upgrading to OCaml 3.11.2 around the same time as the

everyone-- The OCaml bindings need help again. diff -r a8c05e69647e import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml --- a/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Fri Dec 25 17:35:09 2009 -0800 +++ b/import/llvm.org/llvm/bindings/ocaml/llvm/llvm.ml Sun Dec 27 11:38:15 2009 -0800 @@ -42,13 +42,18 @@ | External | Available_externally | Link_once + | Link_once_odr | Weak +

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 second example: >> >>  

Hi James, > Is it my imagination, or is there no way in LLVM 2.8 (or current trunk) to use the facilities defined in<llvm-c/Core.h> to get or set the optional return parameter attribute on a function value? > > All the functions in the "Operations on parameters" parameters section actually seem to work only on the function arguments and not the return parameter. Is this

On Aug 11, 2011, at 11:03 AM, Chris Lattner wrote: > > On Aug 11, 2011, at 5:17 AM, Florian Merz wrote: > >> Hi everyone, >> >> we'd like to be able to check for loss of information in trunc operations in >> our LLVM-based bounded model checker [1]. For this it is important if the >> trunc was on a signed or unsigned integer, so we need nsw and nuw

On Aug 11, 2011, at 11:32 AM, John McCall wrote: >> On Aug 11, 2011, at 5:17 AM, Florian Merz wrote: >> >>> Hi everyone, >>> >>> we'd like to be able to check for loss of information in trunc operations in >>> our LLVM-based bounded model checker [1]. For this it is important if the >>> trunc was on a signed or unsigned integer, so

On Mar 1, 2010, at 04:43, Duncan Sands wrote: > [I wrote:] >> >> Nevertheless, the LLVM Language Reference document suggests, in the examples for the Function Types section, that parameter attributes are part of function types. > > Where exactly? I don't see it in the online version. See <http://llvm.org/docs/LangRef.html#t_function> and look at the second

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)

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?

I'm in the process of finishing up the ocaml llvm bindings, and I had some last minute questions before we code freeze: 1. What version of ocaml is everyone using, and how old of an ocaml version do you need to support? 2. Would it be alright if I renamed some functions? Module providers are being removed for 2.7. I can keep the old functions around, but I'd prefer to keep the API clean.