similar to: [LLVMdev] [PATCH] Fix weak/linkonce linkage in execution engine

Hi, I am using PinaVM which is a prototype of a SystemC front-end based on "LLVM". The only version that it works with is 2.8. Also to test PinaVM, we need llvm-g++ (I think clang does not work). However, when I want to run an example, i get the following error, which i think is related to llvm-g++: reza at RezaUbuntu:~/pinavm-pinavm/systemc-examples/jerome-chain$ make promela

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

The issue here (even if you get dragonegg working) is that the thing that most newer linuxes install when you apt-get llvm-gcc isn't actually llvm-gcc, it's gcc with the dragonegg plugin. Even if the plugin issues are sorted out, the "fake" llvm-gcc doesn't support -emit-llvm so this wouldn't work. You'll probably need to pull a 2.8 of it from llvm.org or a

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/

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

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

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/

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

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

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

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

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

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) : ---

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

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 more than others. Your comment seems to imply that only the tip of each push is

On Wed, Oct 3, 2012 at 10:15 AM, Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> wrote: > 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

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

Matthieu Moy <Matthieu.Moy at grenoble-inp.fr> writes: > 1) How one should behave wrt other LLVM developers, with rules like > "please send patches this way" or "don't git push something that > hasn't been reviewed before", or "here's how you may get a patch > accepted if you're not an LLVM developer". I think this is all