similar to: [LLVMdev] github's llvm mirror down

> LLVM has its own mirror at http://llvm.org/git/llvm.git, if that suits your needs. The llvm.org mirror seems to be quite a bit slower (~3.5x). I think it's because github lets me use the git protocol whereas llvm.org suggests http. When I try to clone "git at llvm.org:git/llvm.git", I'm asked for a password for user 'git'. -Greg On Tue, Mar 4, 2014 at 3:54 PM,

Just curious, what's the reason we don't make the github mirrors the official mirrors? ...besides not knowing how to revive them when they go down. :) -Greg On Tue, Mar 4, 2014 at 5:35 PM, Steven Noonan <steven at uplinklabs.net> wrote: > Someone should enable the smart HTTP protocol: > > https://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html > > On

On Wed, Dec 5, 2012 at 6:01 PM, Greg Fitzgerald <garious at gmail.com> wrote: >> But if you just want to see the code and the diff against upstream... > > If others are interested as well, here's all your changes via Github's > "compare" feature: > > https://github.com/garious/llvm/compare/master...chromium > > Fascinating stuff guys. What a

Hi Michael, > As for actually switching to git. I see no benefit to justify the cost > of switching unless we actually take advantage of git's features. And > I've yet to see anyone propose this. Then I'll be the first. :) The benefit is that the review process would require no file copies or email attachments, shorter email conversations, no copying code during reviews to

Just brainstorming here, but what if each CODE_OWNER maintained a spork on Github and accepted Pull Requests? What's a spork, you ask? Well it's fork with no intent to diverge - it spoons some centralized repo (be it via git or git-svn). If you haven't heard the term 'spork' in this context before, it's either because I just made it up or that we share the same

On Thu, Nov 15, 2012 at 5:17 PM, Greg Fitzgerald <garious at gmail.com> wrote: > Just brainstorming here, but what if each CODE_OWNER maintained a spork on > Github and accepted Pull Requests? What's a spork, you ask? Well it's > fork with no intent to diverge - it spoons some centralized repo (be it via > git or git-svn). If you haven't heard the term

> But if you just want to see the code and the diff against upstream... If others are interested as well, here's all your changes via Github's "compare" feature:

Hi, Has there been discussion about having svn mirror git instead of vice versa? I've been happy with the git+cmake+ninja combo for a while now, but the online docs suggests this configuration is second-class to svn+autotools+make. Is the community transitioning to any particular configuration? Thanks, Greg On Wed, Nov 14, 2012 at 9:19 AM, Anton Korobeynikov <anton at

Hi Greg, Our repos are public already, hosted on the Chromium infrastructure. Our builds are based out of the Native Client repository. The nacl git mirror is at http://git.chromium.org/native_client/src/native_client.git (no gitweb, sorry). That repo has pointers to a bunch of other repos which make pnacl (LLVM, clang, binutils, and a few others. see the file pnacl/DEPS for more). But if you just

You can email the list, what url says that? -Chris > On Jan 20, 2015, at 9:31 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > Ping > >> On Mon, Jan 19, 2015 at 9:52 AM, Greg Fitzgerald <garious at gmail.com> wrote: >> I am not a member of the llvm-admin email list and on the description >> of that page it says, "DO NOT MAIL THIS LIST!"

On Thu, Nov 15, 2012 at 12:01 PM, Greg Fitzgerald <garious at gmail.com> wrote: > Hi Michael, > >> As for actually switching to git. I see no benefit to justify the cost >> of switching unless we actually take advantage of git's features. And >> I've yet to see anyone propose this. > > Then I'll be the first. :) I'd suggest you/others read the

As a temporary fix, you can replace this line in sanitizer_linux_libcdep.c: const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1216, 2304); with const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1168, 2304); The tests should pass after that. I need to figure out which ifdefs to put this under, so I might not be able to land the fix until Monday. On Fri, May 31, 2013 at 8:48 PM, Greg

> I'd suggest you/others read the previous thread discussing this issue. > It's a bit tricky to link to a whole thread in the llvm-dev mail > archive, but here's one part of it: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041738.html Maybe I should add this to the FAQ? Does this look good?: Why don't you move from svn to git? ==============================

LLVM Community, > http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041738.html This was extraordinarily valuable in learning to understand the situation - thank you David Blaikie for pointing me to it. A few key snippets: "Because I optimize for the code reviewer, not the patch submitter," Chris Lattner "Forcing transitioning to git makes no sense for a lot of us - for

Those changes shouldn't affect ARM at all, since everything is under #if defined(__i386__) || defined(__x86_64__). What version of glibc are you building with on x86? On Fri, May 31, 2013 at 7:16 PM, Greg Fitzgerald <garious at gmail.com> wrote: > The failures happen on x86 Linux, Ubuntu Lucid. On ARM Android, my > example code segfaults, whereas before it worked. I

> Cool, can you use clang 3.3 then? :) I can, but digging deeper I see that the compiler-rt sanitizer tests depend on just-built-clang for its object instrumentation. The next time the instrumentation changes, I'd expect those tests to break. If the lit tests that require -fsanitize were moved to the clang repo, then I think it'd be safe to build compiler-rt with clang 3.3 or gcc

I'm hoping to revive the LLD standalone CMake build. I'm new to this build but it looks like it borrowed code from an old version of compiler-rt, which I did some work on last year. Like compiler-rt, I'd like to get the LLD build up running with only CMAKE_PREFIX_PATH instead of defining custom variables like LLD_PATH_TO_LLVM_BUILD and LLD_PATH_TO_LLVM_SOURCE. Any objection to that?

> Why does fork-exec for llvm-symbolizer work, but simple exec(self) does not? Because the llvm-symbolizer the runtime finds is built for the host architecture. This is weird, yes, but once we integrate the symbolizer, it goes away. > Could we write a ulimit-like utility that would do setrlimit and then > exec the specified binary > %run %ulimit -s 8192 %t? I like that idea. How

Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks like everything works great, but that you just need to make those UB tests 'unsupported' since they fail with "libclang_rt.ubsan was built without __int128 support". Thanks, Greg On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov

> What version of glibc are you building with on x86? 2.11.1 for 64-bit x86 linux $ ldd --version ldd (Ubuntu EGLIBC 2.11.1-0ubuntu7.8) 2.11.1 On Fri, May 31, 2013 at 8:24 AM, Sergey Matveev <earthdok at google.com> wrote: > Those changes shouldn't affect ARM at all, since everything is under #if > defined(__i386__) || defined(__x86_64__). > > What version of glibc are