similar to: [LLVMdev] Poll Results: Do you prefer Git or SVN for LLVM development?

I'm curious to know if the LLVM community is deeply split when it comes to version control. If you have a second, could you please vote? http://poll.pollcode.com/i597kq Thanks, Greg

On Mon, Nov 19, 2012 at 12:12 PM, Greg Fitzgerald <garious at gmail.com> wrote: > Thank you everyone for your participation. > > A few flaws in my poll: Also: sample bias. You asked for responses in an email thread talking about git on an essentially wide-open mailing list. I don't think that any conclusions about the actual development community of LLVM can be drawn from such

Greg Fitzgerald <garious at gmail.com> writes: > I'm curious to know if the LLVM community is deeply split when it > comes to version control. If you have a second, could you please > vote? > > http://poll.pollcode.com/i597kq The result of this poll has little value in practice. In the past the project leader stated that the opinions of the most active contributors

For starters, I hope the results of this poll can help guide how the GettingStarted page is written. http://llvm.org/docs/GettingStarted.html I'd imagine the most active contributors do not find themselves referencing this page too often, but as a newcomer, I feel it could use some work. Git is second class, CMake gets nothing but a passing reference, and Ninja is not even mentioned.

> I'd imagine the most active contributors do not find themselves > referencing this page too often, but as a newcomer, I feel it could > use some work. This has been in the back of my mind for a while, and I think it is probably true. I think that it would be more useful if you did a poll specifically aimed at new contributors (simple rough criterion: new contributor === doesn't

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

> 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,

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!"

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

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

On 17 October 2012 22:23, Greg Fitzgerald <garious at gmail.com> wrote: > I had to move MCELF.h to "include/llvm/MC" and added a > MCELFStreamer.h to the same directory. That okay to do? This is not a trivial question, and I'll let others chip in. Superficially, you'd think so and it might make sense in the long run, but you have to consider why it wasn't there

> execv(argv[0]) is a canonical way to restart the > process, it's sad that the emulator interferes with that. We have the option to emulate the instruction set or emulate the OS. The former is lighter weight and easy to configure. The downside is that system calls route to the host system. That can be useful if, for example, the executable invokes llvm-symbolizer. While

It's been 4 days since Github's llvm mirror has been updated. Anybody know who maintains this? https://github.com/llvm-mirror Thanks, Greg

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!" So how do we contact the LLVM admins? I'm hoping to add the '--use-log-author' flag to the git mirrors'. Thanks, Greg

> const uptr kThreadDescriptorSize = FIRST_32_SECOND_64(1168, 2304); Yes, that change causes all tests to pass. > I need to figure out which ifdefs to put this under, so I might not be able to land the fix until Monday. Okay, no worries, thanks for doing this. I've moved over to release_33 for the short-term. With the one change mentioned earlier (#include <stdint.h>), asan