similar to: [LLVMdev] submitting patch series

I'm trying to cross-compile LLVM with build=, host=target=. I'm using the following packages from Debian lenny: mingw32 4.2.1.dfsg-1 mingw32-binutils 2.18.50-20080109-1 mingw32-runtime 3.13-1 The first problem I hit was when I configured with CC, CXX, AR and RANLIB set to mingw cross-tools, but forgot to specify NM as well. This resulted in a load of warnings that scrolled off the

Hi, I've just tried to run the test-suite, for the first time in ages. It stops rather abruptly with: $ make TEST=nightly report report.html /home/jay/llvm/local/bin/llvm-gcc -I/home/jay/llvm/gitobjdir/projects/test-suite/SingleSource/UnitTests -I/home/jay/svn/llvm-project/test-suite/trunk/SingleSource/UnitTests -I/home/jay/git/llvm/projects/test-suite/include -I../../include

I've always found the name ComputeMaskedBits a bit unintuitive, and since r154011 it's even worse because there is no masking going on whatsoever: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120402/140280.html Is there any appetite for a global rename to ComputeKnownBits? Or any other better names? Thanks, Jay.

(Resending with the correct mailing list address.) Hi, Currently test/asan/TestCases/alloca_vla_interact.cc is XFAILed for powerpc64. I've had a look at why it doesn't work. I think the only problem is in the call to __asan_allocas_unpoison that is inserted at the end of the "for" loop (just before a stackrestore instruction). The call function is created something like this

The following bugs look like they only relate to llvm-gcc. Can they be closed, as llvm-gcc is no longer supported? http://llvm.org/bugs/show_bug.cgi?id=3636 http://llvm.org/bugs/show_bug.cgi?id=5011 http://llvm.org/bugs/show_bug.cgi?id=6764 http://llvm.org/bugs/show_bug.cgi?id=8451 http://llvm.org/bugs/show_bug.cgi?id=9310 http://llvm.org/bugs/show_bug.cgi?id=9311

On 13 February 2012 09:22, Jay Foad <jay.foad at gmail.com> wrote: > Would it be possible to use CityHash instead for strings? > > http://code.google.com/p/cityhash/ Incidentally there was talk of using CityHash for LLVM's StringMap last year, but I don't think it ever came to anything: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014656.html Jay.

In LowerGET_DYNAMIC_AREA_OFFSET() you're calling MFI->getMaxCallFrameSize(), but it looks like that doesn't return useful information until after the PrologEpilogInserter's PEI::calculateCallsInformation() has run. So maybe the lowering has to be done as part of frame index elimination? (I'm not too familiar with this code.) Jay. On 23 November 2015 at 13:07, Jay Foad

How about tweaking the compiler-rt cmakefiles so that if lsan is not supported, the target check-lsan still exists but does nothing? I've attached a patch that does this. (I don't know much about cmake so there might be a better way of doing it.) Alternatively, can I change the zorg build script so that "run sanitizer tests in gcc build" doesn't try to run check-lsan etc

On 6 May 2011 09:29, Jay Foad <jay.foad at gmail.com> wrote: > I've just tried to run the test-suite, for the first time in ages. It > stops rather abruptly with: > > $ make TEST=nightly report report.html > > /home/jay/llvm/local/bin/llvm-gcc > -I/home/jay/llvm/gitobjdir/projects/test-suite/SingleSource/UnitTests >

On 11 November 2010 12:49, Jay Foad <jay.foad at gmail.com> wrote: > Delving a bit deeper, the difference seems to be that symbol "i" in > the assembler source: > >        .type   i, at object               # @i >        .section        .tdata,"awT", at progbits >        .globl  i >        .align  4 > i: >        .long   7                      

Hi, This document tells me how to do a "read-only GIT clone of LLVM": http://llvm.org/docs/GettingStarted.html#git_mirror Can someone please document how to get read-write access using git or git-svn, if it's possible? Or do I still have to use plain old svn to commit? (I have tried searching the mailing list to find out how to do this, but it seems like a lot of the information

On 13 May 2014 21:27, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 13 May 2014 14:33, Jay Foad <jay.foad at gmail.com> wrote: >> I've always found the name ComputeMaskedBits a bit unintuitive, and >> since r154011 it's even worse because there is no masking going on >> whatsoever: >> >>

On Thu, Jul 7, 2011 at 12:55 AM, Jay Foad <jay.foad at gmail.com> wrote: >> 1. Clang - Jay, do you have a patch for this? > > Yes. It's good enough to build most of LLVM+Clang, except for a couple > of files. But I'm running out of time and expertise to be able to fix > the remaining bits. Some specific concerns: > > 1. Many Objective-C(++) tests fail, because

Hi Jay, they all seem to work with dragonegg, so I closed them. Ciao, Duncan. On 04/05/12 13:37, Jay Foad wrote: > On 1 May 2012 12:34, Jay Foad<jay.foad at gmail.com> wrote: >> The following bugs look like they only relate to llvm-gcc. Can they be >> closed, as llvm-gcc is no longer supported? > > Also: > > http://llvm.org/bugs/show_bug.cgi?id=1375 >

On Nov 8, 2011, at 7:18 AM, Jay Foad wrote: > On 7 November 2011 22:00, Bill Wendling <wendling at apple.com> wrote: >> We are starting on our third (and hopefully last) round of testing for LLVM 3.0. Please visit: >> >> http://llvm.org/pre-releases/3.0/rc3/ >> >> for the sources. There are also binaries for Darwin up there, with more to come during

I've updated the release notes for all API changes I've made since 2.9 was branched: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110711/123990.html > Preferably all in the same place, in order, with (approx.) revision > numbers where it happened. It'd make our jobs much easier to merge our > local base with trunk. I haven't gone into quite that much

Hi, My New Year's resolution is to complain (constructively) whenever I get a spurious build failure email from a buildbot. For new or infrequent contributors especially, they can be extremely confusing and unnecessarily alarming. This one below is the first build ever attempted by the builder, so how on earth can it have come up with a meaningful blame list? And in any case, surely we

Cygwin's <stdint.h> defines uint32_t as "unsigned long". I think this is valid, but it causes various problems like this when building LLVM with GCC 3.4.4: .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:3440: error: call of overloaded `AddInteger(uint32_t)' is ambiguous .../lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1429: error: no matching function for call to `max(long

> - a "configure"-based build only seems to know about projects/sample/ > and projects/test-suite/, and I couldn't find any way to get it to > build projects/lld/. I investigated a bit more. llvm's autoconf/configure.ac says: dnl Configure all of the projects present in our source tree. While we could dnl just AC_CONFIG_SUBDIRS on the set of directories in projects

On Oct 20, 2009, at 5:49 AM, Jay Foad wrote: >> To test clang: >> 1) Compile llvm and clang from source. > > LLVM fails to build for me on Cygwin. I get: > Does TOT build? If not, please file a bug. Unfortunately Cygwin is not in our release criteria. I'd like to have a buildbot running (if there is not one already) and then get someone to qualify it for the