similar to: [LLVMdev] git Mirrors

Hi everyone, I tried to clone the git mirrors and set up git-svn metadata according to these instructions: http://llvm.org/docs/GettingStarted.html#git-mirror Importantly, I did this (replacing <username>, of course): % git svn init https://llvm.org/svn/llvm-project/llvm/trunk --username=<username> % git config svn-remote.svn.fetch :refs/remotes/origin/master % git svn rebase -l #

> Is there an official Git mirror for Dragonegg? Cannot find the URL with Google > nor with guesswork. Dragonegg has svn. http://llvm.org/svn/llvm-project/dragonegg/trunk Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667

Chen, Teemu is asking "the official git mirror" and he oughta know where the svn repo is. ;) Teemu, I have created an unofficial one; https://github.com/chapuni/dragonegg Excuse me, I might not update it so frequently. Anton, please provide us the official dragonegg.git! ...Takumi

Is there an official Git mirror for Dragonegg? Cannot find the URL with Google nor with guesswork. Teemu

Hi Sean, On 14/11/12 23:53, Sean Silva wrote: > Sorry for the bother Jim, but I'm calling on you again for guidance > about llvm-gcc mentions. What should be done about the mention of > llvm-gcc on <http://llvm.org/docs/TestSuiteMakefileGuide.html>? Can we > just roughly s/llvm-gcc/clang/ ? Daniel, feel free to provide guidance > as well. to some extent llvm-gcc lives on

On Tuesday 27 April 2010 11:01:16 Renato Golin wrote: > On 27 April 2010 16:46, David Greene <dag at cray.com> wrote: > > It shouldn't be very hard for the compiler to detect the second case. > > It's a pretty straightforward pattern.  For everything else it would > > have to assume case #1. > > The only problem is that threads are rarely within language

Hi, > > Anton, please provide us the official dragonegg.git! > Done! Has the link been put on the dragonegg website? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667

On 01/28/10 09:49, Christian Plessl wrote: > Due to a current need to have a git mirror for LLVM, I'm resurrecting this old thread. > > I'm aware that there exist already LLVM git mirrors at git://repo.or.cz/llvm.git and git://github.com/earl/llvm-mirror.git However, these repositories only mirror the current SVN trunk and do no provide any branch and tag information, which

Due to a current need to have a git mirror for LLVM, I'm resurrecting this old thread. I'm aware that there exist already LLVM git mirrors at git://repo.or.cz/llvm.git and git://github.com/earl/llvm-mirror.git However, these repositories only mirror the current SVN trunk and do no provide any branch and tag information, which would be very convenient for creating experimental branches

> Anton, please provide us the official dragonegg.git! Done! -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Good morning, Dave. On Thu, Feb 24, 2011 at 4:17 AM, David A. Greene <greened at obbligato.org> wrote: > Do git repositories cloned from git-svn mirrors work properly?  For > example: > >                         svn >                          ^ >                          | >                          | >                          V >                       git-svn

Anton Korobeynikov <anton at korobeynikov.info> writes: > Hello Everyone > > As you might already know, git mirrors of llvm repository started from > repo.or.cz mirrors, where stuff was pushed almost by hands out of > git-svn local copy. Right now we have official and automatically > updated GIT mirrors on llvm.org and thus repo.or.cz mirrors look a bit > redundant.

Hi, This probably isn't significant evidence about using svn as the authoritative revision control system for llvm but more just to point out that the svn users tend to consider that the only thing one would use revision control for is the mainstream development history tracking. I'll note that I during working ("development" but also bug-fixing and experimentation) since the

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

Tobias Grosser <tobias at grosser.es> writes: > The very same should work for Pure, dragonegg and basically any > compiler based on LLVM. So I do not want to change clang at all > (except of possibly linking to -lcuda). Why is this a requirement? I think it's completely unrealistic to expect to be able to do this without driver changes. If you don't want to change clang,

Eric Christopher <echristo at gmail.com> writes: > On Thu, Jun 19, 2014 at 11:52 AM, <dag at cray.com> wrote: > >> Is svn metadata missing from some of the upstream git mirrors? I really >> don't want to git-svn fetch if I can avoid it. > > I use it for clang and llvm. I haven't tried for the others. According to the web page, it should at least work

Hi Jin Gu Kang, > I made a patch for llvm-gcc about 2 weeks ago. > But no one reviewed my patch. > Reason of patch was following. > >> struct T { > >> struct T (*p)(void); > >> } t; the recent LLVM type system changes broke llvm-gcc in several ways, this is just one of them. All such problems are fixed in dragonegg by not converting "T" when

On 05/08/2012 09:15 PM, dag at cray.com wrote: > Tobias Grosser<tobias at grosser.es> writes: > >> The very same should work for Pure, dragonegg and basically any >> compiler based on LLVM. So I do not want to change clang at all >> (except of possibly linking to -lcuda). > > Why is this a requirement? I think it's completely unrealistic to > expect to

On Tuesday 15 September 2009 08:16, Olivier Meurant wrote: > llvm-gcc -v > Using built-in specs. > Target: i686-pc-linux-gnu > > gcc -v > Using built-in specs. > Target: i486-linux-gnu Different targets. It's no surprise 486 code would perform much worse than i686 code. These compilers need to target the same architecture. Ideally the Makefile would include

On Tue, May 8, 2012 at 9:29 AM, <dag at cray.com> wrote: > Tobias Grosser <tobias at grosser.es> writes: > > > So why the intrinsic? I want to create the PTX string from an LLVM-IR > > optimizer pass, that should be loaded into clang, dragonegg, opt, .. > > You want to codegen in the optimizer? I'm confused. > > An LLVM-IR optimizer pass does not