search for: verimag

Hi, The link "Broken versions of GCC and other tools" on http://llvm.org/docs/ReleaseNotes.html points to #brokengcc, where it should point to http://llvm.org/docs/GettingStarted.html#brokengcc I guess. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

...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 the other hand, will tell you. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

...r 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 is 2345, can you tell whether your trunk has this bugfix applied by looking at revision numbers? -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Hi all, I have an LLVM bitcode file, with several functions in it. I'm trying to inline these functions as much as possible, so that I can obtain a big single function. There is opt -inline, but it is not sufficient. Any idea ? -- Julien Henry http://www-verimag.imag.fr/~jhenry/

...y to > llvm::TargetMachine::addPassesToEmitWholeFile (it has a default > value, but one must update the declaration of redefinition of this > function in derived classes). > > - TargetAsmInfo changed to MCAsmInfo in back-end writters. > > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/

...bbed... Name: 0002-JIT-fix-linkage-of-weak-and-linkonce-symbols.patch Type: text/x-diff Size: 2880 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110315/f74220f3/attachment-0001.patch> -------------- next part -------------- -- Matthieu Moy http://www-verimag.imag.fr/~moy/

...ion, git rebase -i and git commit --amend are your friends". 1) should be something people really agree on, and it people want it to be as close as possible to the existing flow. 2) is a matter of personnal choice (advanced Git users won't need to read it). -- Matthieu Moy http://www-verimag.imag.fr/~moy/

...o.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/

...ally call a "branch" (i.e. the set of commits reachable from the ref) : A --- B \ \ C --- D --- E <--- master Commits B and C will have the same generation numbers. I hardly see a context where they could be used by end users as commit identifiers. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

...seNotes.html: - New argument DisableVerify to llvm::TargetMachine::addPassesToEmitWholeFile (it has a default value, but one must update the declaration of redefinition of this function in derived classes). - TargetAsmInfo changed to MCAsmInfo in back-end writters. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

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

...been trained to think that history has to be somewhat linear, and perhaps even that the trunk branch is the only one needing QA attention. Migration from SVN to Git is hard because you have to change the mental model, not just command names and how revisions are named. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

..." are just great for that) to clean it up, and then > have it accepted by upstream. Ideally, you make sur the testsuite passes > for each commit before pushing. > > If you like incremental development, you're going to love DVCS. > > -- > Matthieu Moy > http://www-verimag.imag.fr/~moy/

David, A few comments. > Naming Upstream > --------------- > > The intial clone from upstream results in a git remote reference with > the rather unhelpful name of "origin." As more remote sources get > added, it is easy to forget what "origin" is. Therefore, add a remote > with a more descriptive name. > > git remote add llvm-upstream

...* What's the rationale for including -fno-rtti in `llvm-config --cxxflags`? Is this a bug? If not, it should be mentionned in the release notes for 2.7. * How can a user (like me) of the LLVM library derive from LLVM classes and use rtti information? Thanks, -- Matthieu Moy http://www-verimag.imag.fr/~moy/

NAKAMURA Takumi <geek4civic at gmail.com> writes: >> I don't think one can share commits from clone A to/from clone B without >> going through the parent git-svn repository.  Is that right?  I recall >> having read something about that somewhere. > > Maybe sure on git-svn's branch (eg. master). > "master" should never be pushed to

...39;t notice that C1/C2 and C1'/C2' are meant to be the same, and do awkward things instead of a clean merge. So, you may pull from a clone to another, but you cannot alternatively pull from a clone to another and rebase on upstream without getting into trouble. -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Hi all, At some points of my program, I would like to know if some LLVM values are live or not. For that, I'm using the LiveValues pass, which gives me methods such as : isLiveThroughBlock(Value * v, BasicBlock * b) isKilledInBlock(Value * v, BasicBlock * b) * If I understand well the code, dominator trees are used to compute the LiveThrough blocks. The definition of dominator in graph

On Jul 21, 2011, at 5:18 AM, Tobias Grosser wrote: On 07/21/2011 01:44 PM, Joerg Sonnenberger wrote: On Thu, Jul 21, 2011 at 12:26:29PM +0100, Jay Foad wrote: On 21 July 2011 11:50, Joerg Sonnenberger<joerg at britannica.bec.de<mailto:joerg at britannica.bec.de>> wrote: There is still the major regression with unreadable version numbers. ... The problem is answering the question of

On Jul 21, 2011, at 8:22 AM, Matthieu Moy wrote: > 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