similar to: [LLVMdev] How to contact LLVM admins?

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

Below is a copy of the email I sent to llvm-admin. If it is lost in the ether, can you reply on this thread? There's an LLD contributor looking to add an ARMv7 backend. It's a significant contribution so I'd like to land the patch under the correct author. Hi LLVM admins, I'd like to commit patches on behalf of others, but I'm not comfortable simply adding "Patch by

> We have had no trouble using "Patch by <name>" as the form of attribution for a > lot of years with contributions from a wide range of companies. So I'm not really > inclined to change a process which leaves the system of record *exactly* the > same (a textual acknowledgement of attribution) and only makes one mirror of > it superficially better. Adding

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,

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'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?

Thank you everyone for your participation. A few flaws in my poll: 1) Favoring Git: Subversion supporters are more likely to be split between the last two options. 2) Favoring SVN: Timing of the poll went from Friday night to Monday morning, which probably favored the open source community to 9-to-5ers on private forks. 3) Favoring radicals: Too easy to cheat. Requiring a login or email address

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

> 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

> 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

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

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

> 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

> 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

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

For me, UBsan fails with clang 3.2 and passes with clang 3.3. Using a fixed version allows you to build all clang/llvm/compiler-rt with one compiler. It simplifies the build process quite a bit. Also better for isolating regressions in compiler-rt, especially if you use git-bisect. Greg On May 29, 2013, at 12:30 AM, Alexey Samsonov <samsonov at google.com> wrote: > UBsan tests work

Alexey, >> Some good news, the drivers (both gcc and clang) allow us to put the >> '-L' parameters after the '-l' parameters. I made these changes locally and it went really well. The patch to clang is quite small and only one unit-test needed updating. In compiler-rt, I updated the flags passed to clang to include a '-L${COMPILER_RT_BINARY_DIR}/lib' and

> What is the exact line you use to configure build tree, and the output you see? cmake ../.. \ -G Ninja \ -DCMAKE_INSTALL_PREFIX=ship \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_ASSERTIONS=ON \ -DLLVM_TARGETS_TO_BUILD=ARM \ -DLLVM_DEFAULT_TARGET_TRIPLE=arm-none-linux-gnueabi \ -DLLVM_TARGET_ARCH=arm-none-linux-gnueabi \ -DLLVM_LIT_ARGS=-v ninja check-all