similar to: [LLVMdev] assembler verification tools

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,

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?

On 5 February 2013 23:21, Greg Fitzgerald <garious at gmail.com> wrote: > > Is this for inline asm? > > Yep > In that case, using GAS is always a better options... for now. ;) What I'd prefer to see is if the integrated-as doesn't recognize the > option, clang should report a warning and switch to the 'no-integrated-as' > path. Thoughts? > The

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

How do you feel about adding LLD to the LLVM repo? Could it follow the same path as the integrated assembler? That is, Clang keeps it off by default for each architecture until it's ready for prime time. -Greg On Thu, Jan 8, 2015 at 3:31 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Wed, Jan 7, 2015 at 6:38 PM, Greg Fitzgerald <garious at gmail.com> wrote:

> 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 8 January 2015 at 19:46, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, Jan 8, 2015 at 4:35 PM, Greg Fitzgerald <garious at gmail.com> wrote: >> >> How do you feel about adding LLD to the LLVM repo? Could it follow >> the same path as the integrated assembler? That is, Clang keeps it >> off by default for each architecture until

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

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

> Not that I know of, and I always build compiler-rt natively, together with Clang and LLVM. :( Do you mean "natively on ARM" or "natively on X86 with the ARM target enabled"? If the former, do you have a script to merge the target libs into the host's install directory? If the latter, that'll only build the X86 versions of the compiler-rt libraries. > Would