similar to: [LLVMdev] Any Mercurial or Bazaar mirrors available?

On Jul 26, 2008, at 7:56 PM, Óscar Fuentes wrote: > Having a private branch would be handy for some experiments I'm > doing. Two years ago there was an announcement by Owen Anderson, but > the > repo seems down now. > > -- > Oscar > I haven't maintained that for a long time. I think there are some community members who use git mirrors, though. --Owen

Owen Anderson <resistor at mac.com> writes: > On Jul 26, 2008, at 7:56 PM, Óscar Fuentes wrote: >> Having a private branch would be handy for some experiments I'm >> doing. Two years ago there was an announcement by Owen Anderson, but >> the repo seems down now. > > I haven't maintained that for a long time. I think there are some > community members

Hello, Oscar > Anyways, if there is no Mercurial or Bazaar mirrors available, I will > try git. Recommendations on which one to use welcomed. There is git mirror at repo.or.cz: http://repo.or.cz/w/llvm.git, llvm-gcc & clang mirrors are available there as well. I'm updating it 'by hands' currently due to some reasons, so sometimes it will need 2-3 days for changes in llvm

I've been using git-svn successfully as a distributed front-end for Subversion repositories. You get a complete, local Git repository from where you can commit and update to/from Subversion. It works quite well, actually. Native Windows is entirely unsupported by Git at the moment, but I hear it works well under Cygwin. - Simon 2008/7/27 Óscar Fuentes <ofv at wanadoo.es>: > Owen

Owen Anderson <resistor at mac.com> writes: > On May 13, 2008, at 1:30 AM, kr512 wrote: >> >> Nevertheless, LLVM is not provided as a ready-to-use DLL, >> unfortunately. > > This is exactly why I asked if you had downloaded and compiled it. If > you had, you might have noticed that it does produce a set of ready-to- > use shared libraries. I'm sorry

Time ago when the svn server was crawling due to massive hammering from people mirroring the repo, someone said that after the 2.6 release we could discuss creating official mirrors for those who work with svn clients based on distributed VCSs such as git and bazaar. Such mirrors increase productivity (facilitating experimentation and parallel tasks, allowing off-line work) and even lessens the

On May 13, 2008, at 6:38 PM, Óscar Fuentes wrote: > Last time I checked, building LLVM on Windows (MinGW or MSVC) did not > produce dlls. > > Has this changed? > > I was succesful converting the libraries produced by MinGW to dlls, > though. > It's a little bit immaterial whether they're shared or static libraries, since one would be distributing them bundled

On Oct 28, 2009, at 8:30 AM, Óscar Fuentes wrote: > Time ago when the svn server was crawling due to massive hammering > from > people mirroring the repo, someone said that after the 2.6 release we > could discuss creating official mirrors for those who work with svn > clients based on distributed VCSs such as git and bazaar. > > Such mirrors increase productivity

Owen Anderson <resistor at mac.com> writes: > On May 13, 2008, at 6:38 PM, Óscar Fuentes wrote: >> Last time I checked, building LLVM on Windows (MinGW or MSVC) did not >> produce dlls. >> >> Has this changed? >> >> I was succesful converting the libraries produced by MinGW to dlls, >> though. > > It's a little bit immaterial whether

Chris Lattner <clattner at apple.com> writes: > You need to separate "what is good for David" from "what is good for > the project". Encouraging decentralized development and long-lived > branches is not actually in the best interest of the project. > > I agree that there are some (quite minor IMO, like offline commits) > advantages that git can

> After git, mainline will still be the most important branch for the > *project*, > but you will work with quite a few branches on parallel. > > Who's mainline? :) Be prepared to assign a super-merger, like Linus, to maintain the "mainline". The git workflow works really really great, but it does require getting rid of mainline thinking. It doesn't exist.

Duncan Sands <baldrick at free.fr> writes: >> But you put me on the right track. The problem is that the class is >> returned on the stack. Correction: The class is returned on the FP stack: >> 0x6e08b5b5 <_ZN3Foo6GetFooEv+17>: fldl -0x8(%ebp) >> 0x6e08b5b8 <_ZN3Foo6GetFooEv+20>: leave >> 0x6e08b5b9 <_ZN3Foo6GetFooEv+21>:

On Sat, Jul 23, 2011 at 01:02:10AM +0200, Óscar Fuentes wrote: > One thing that I wanted to see (and probably missed, because I didn't > read all the thread) is to discuss the workflow. I'm under the > impression that not all regular LLVM developers understand the > implications for the LLVM community of migrating from a central VCS to a > distributed one, on terms of

Joerg Sonnenberger <joerg at britannica.bec.de> writes: > You know, this is exactly the crux of this whole "move to git" thread. > It is the very same problem of every other VCS migration I have seen (or > dealt with). The core issue here is that you are effectively telling us > that the current workflow is not supported by Git. It is supported, but if you want to

fly language <flylanguage at gmail.com> writes: >> After git, mainline will still be the most important branch for the >> *project*, >> but you will work with quite a few branches on parallel. >> >> > Who's mainline? :) Be prepared to assign a super-merger, like Linus, to > maintain the "mainline". > > The git workflow works really

Not that I sympathize with the OP's manners but... Bill Wendling <isanbard at gmail.com> writes: > On May 10, 2008, at 7:55 PM, kr512 wrote: > >> See how gcc is invoked to generate the final executable >> file. This means LLVM is an incomplete backend, >> unfortunately. >> > That's only a convenience. GCC generates assembly code too and calls

> On Jan 16, 2015, at 3:26 AM, Erik de Castro Lopo <mle+cl at mega-nerd.com> wrote: > > As for all the reason why the LLVM project does not use Git, I wonder > why large complex projects like the Linux kernel, Wine, MinGW-w64, > GHC and many many others don't seem to have any major problems using > Git. Lots of projects are also happy with Mercurial, or BZR, or even

Take a look at llvm-gcc. Look for HandleAggregateShadowArgument. Evan On Mar 26, 2008, at 10:31 AM, Óscar Fuentes wrote: > Óscar Fuentes <ofv at wanadoo.es> writes: > >> BTW, -fpcc-struct-return solves the case that motivated this thread. > > -fpcc-struct-return is an ABI change, hence it requires "compiling the > world". Not acceptable. > > I'll

Hi owen, Can you please elaborate as to what should I do? Find all the instruction which have r2 in it and replace all of them with r1 and then remove the load instruction? Thanks Abhinav ----- Original Message ----- From: "Owen Anderson" <resistor at mac.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Friday, November 14, 2008 11:22:32 PM

On Nov 19, 2009, at 10:25 AM, Jon Harrop wrote: > > >> In this case, the assertion that LLVM is slow is correct: it's >> definitely slower than a non-optimizing compiler. > > I'm *very* surprised by this and will test it myself... Compared to a compiler in the same category as PCC, whose pinnacle of optimization is doing register allocation? I'm not