similar to: [LLVMdev] Broken link on http://llvm.org/docs/ReleaseNotes.html#brokengcc

Thanks, I must have missed these, added. On Apr 22, 2010, at 1:28 AM, Matthieu Moy wrote: > Chris Lattner <clattner at apple.com> writes: > >> Ok, the LLVM 2.7 release notes are in near final shape. Please take >> a look and suggest improvements (or, better yet, just commit >> improvements if you have commit access): > > About the API changes, some that hit

Chris Lattner <clattner at apple.com> writes: > Ok, the LLVM 2.7 release notes are in near final shape. Please take > a look and suggest improvements (or, better yet, just commit > improvements if you have commit access): About the API changes, some that hit me when I ported some code to LLVM 2.7, and not in the release notes (I had sent a private email some time ago) : ---

greened at obbligato.org (David A. Greene) writes: > Actually git pull can sometimes get you into trouble. Probably git > fetch / git rebase is the better combination for LLVM. I don't get it. Doesn't "git pull --rebase" do exactly a fetch followed by a rebase? -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Hi, I've had problem with a program using LLVM that tried to dynamic_cast objects created in the JIT execution engine, from the native part of the program (for the curious, the program is PinaVM http://gitorious.org/pinavm/pages/Home). I've narrowed down the issue to the linkage of weak_odr and linkonce_odr symbols, used for the vtables, and that _must_ be unique for dynamic_cast to

Joerg Sonnenberger <joerg at britannica.bec.de> writes: > The problem is answering the question of "do I have it or not". Linear > version numbers are much nicer for that. In the presence of branches, the version number alone doesn't answer this question, because the commit may be more recent than your HEAD, but in another branch. git branch --contains <sha1>, on

John McCall <rjmccall at apple.com> writes: >> git branch --contains <sha1>, on the other hand, will tell you. > > Of course, this doesn't actually help if you've cherry-picked commits > over to your branch (e.g. because it's a release branch). How is that different from SVN? If revision 1234 fixes a bug is some branch, and the last revision in your trunk

greened at obbligato.org (David A. Greene) writes: >> b) We need a document explaining how patches are reviewed and referred >> to, what commit rules (and hooks) are in place and how this would work >> in a git world. It would be short and sweet. > > I'm not exactly sure what you're asking for. My assumption is that the > hooks in place for git are the same

Alexander MacDonald <alexmac at adobe.com> writes: > The topic of generation numbers has come up again recently on the git > lists and it looks like they might make it in > (http://stackoverflow.com/questions/6702821/ > git-commit-generation-numbers). Of course this isn't exactly the same > as svn because the numbers are only unique within a given branch, but > it

On Jul 23, 2011, at 4:34 AM, Matthieu Moy wrote: > Chris Lattner <clattner at apple.com> writes: > >> I really do appreciate distributed VCS, but only as staging. >> Incremental development is crucial for the project and "take this git >> push with 100K of code" will never be acceptable. > > Incremental development is probably promoted by DVCS far

Andrew Trick <atrick at apple.com> writes: > SVN revision numbers are central to my workflow. I use them to tag > results generated against various builds. I like those results sorted > by time and the chronology should be obvious, This means in the presence of branches, you want the ordering to be [branch A] build 1 [branch B] build 2 [branch A] build 3 [branch C] build 4 ? It

Ok, the LLVM 2.7 release notes are in near final shape. Please take a look and suggest improvements (or, better yet, just commit improvements if you have commit access): http://llvm.org/docs/ReleaseNotes.html Things still needed are marked with FIXMEs. These include: 1. Clang needs a blurb describing what's new in 2.7. Have the clang folks been doing anything for the last 6 months? 2. I

Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes: > greened at obbligato.org (David A. Greene) writes: > >> Actually git pull can sometimes get you into trouble. Probably git >> fetch / git rebase is the better combination for LLVM. > > I don't get it. > > Doesn't "git pull --rebase" do exactly a fetch followed by a rebase? No. It does

Hi, I'm trying to port a piece of code using LLVM as a library to the latest SVN version. One difference between 2.6 and 2.7svn is that `llvm-config --cxxflags` now include -fno-rtti. Since my code does use RTTI information (in non-trivial dynamic_cast), my code can't compile with this. Same goes for -fexceptions. I've tried setting my CXXFLAGS to `llvm-config --cxxflags` -frtti

Anton Korobeynikov <anton at korobeynikov.info> writes: >> What options were used with git-svn init?  It certainly can support >> multiple branch/tag directories: >> >> init >>  --tags=<tags_subdir> >>  --branches=<branches_subdir> >> >>  You can specify more than one --tags and/or --branches options, in >>  case your

Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes: > dag at cray.com (David A. Greene) writes: > >> Jason Kim <jasonwkim at google.com> writes: >> >>> I believe git has a similar system for maintaining "branches of patches"  >> >> A pointer/tutorial on how to do this would be most welcome. > > It depends on the definition of

greened at obbligato.org (David A. Greene) writes: >> Each clonee should do "git-svn dcommit" individually. >> (and it would be happier if you did "git pull --rebase llvm.org) > > Yep. > >> Of course, other branches may be push/pull-ed among repos. It is git! > > Does this mean that clone B can pull from clone A and vice-versa? The problem is 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

dag at cray.com (David A. Greene) writes: > Jason Kim <jasonwkim at google.com> writes: > >> I believe git has a similar system for maintaining "branches of patches"  > > A pointer/tutorial on how to do this would be most welcome. It depends on the definition of "branches of patches" ;-). I manage my patches with "git rebase -i", which

dag at cray.com (David A. Greene) writes: > But none of this explains how to prevent false conflicts when updating > your git workarea from the svn git mirror. The problem is that dcommit > changes the hash from what's in your local repository to something > different. When you then update from the git mirror, you get a conflict > because two commits with different hashes

Preston Briggs <preston.briggs at gmail.com> writes: > Think about costs asymptotically; that's what matters. Calls and > returns require constant time, just like addition and multiplication. Constant time, but not necessarily constant memory. Deep recursion will blow up your stack (AKA "segmentation fault" :-( ) if the compiler could not optimize it (tail recursion