similar to: [LLVMdev] bug 3367

On May 22, 2009, at 12:02 PM, Jay Foad wrote: >> It'd be good for someone actually familiar with invoke could comment >> >> on this. Specifically, in the following testcase, the return value of >> >> the invoke is used in the unwind destination, which is not reachable >> >> from the normal destination. Should this be valid? >> > > No. If

> ... and it's in.  Please let me know if you see any problems. My clang self-hosted build (Release+Asserts on Release+Asserts, Linux x86_64) fails with: make[2]: Entering directory `/home/jay/llvm/objdir-self/tools/opt' llvm[2]: Compiling GraphPrinters.cpp for Debug+Asserts build clang: /home/jay/svn/llvm-project/llvm/trunk/include/llvm/Support/Casting.h:194: typename

On May 22, 2009, at 10:13 AM, Dale Johannesen wrote: > Should we document it then? Invokes are confusing enough without > relying on undocumented behavior:) It'd be good for someone actually familiar with invoke could comment on this. Specifically, in the following testcase, the return value of the invoke is used in the unwind destination, which is not reachable from the normal

> It'd be good for someone actually familiar with invoke could comment > on this. Specifically, in the following testcase, the return value of > the invoke is used in the unwind destination, which is not reachable > from the normal destination. Should this be valid? No. If the invoked function unwinds then it doesn't return a value. I'm pretty sure that -verify will reject

>> No. If the invoked function unwinds then it doesn't return a value. >> I'm pretty sure that -verify will reject your testcase. > > Thanks to you and others for answering this. I've added a sentence to > LangRef.html making this explicit. I've had a go at documenting a bit more rigorously how phi and invoke instructions affect the SSA form. Patch attached.

Hi, http://llvm.org/bugs/show_bug.cgi?id=3367 http://llvm.org/bugs/show_bug.cgi?id=3831 These bugs are both cases where the optimizers are generating incorrect code. They have simple test cases and reasonably straightforward fixes. I've just done a successful test-suite run on i686-pc-linux-gnu with both fixes included. Can you please consider applying the fixes? Thanks, Jay.

Jay Foad wrote: >> ... and it's in. Please let me know if you see any problems. > > My clang self-hosted build (Release+Asserts on Release+Asserts, Linux > x86_64) fails with: > > make[2]: Entering directory `/home/jay/llvm/objdir-self/tools/opt' > llvm[2]: Compiling GraphPrinters.cpp for Debug+Asserts build > clang:

Jay, On Mar 30, 2009, at 10:29 AM, Jay Foad wrote: > Hi, > > http://llvm.org/bugs/show_bug.cgi?id=3367 > http://llvm.org/bugs/show_bug.cgi?id=3831 > > These bugs are both cases where the optimizers are generating > incorrect code. They have simple test cases and reasonably > straightforward fixes. I've just done a successful test-suite run on > i686-pc-linux-gnu

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

(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

Jay, do you have a PowerPC64 target? If so, could you please check attached patch on PPC box? This is a draft patch, but it would be nice to make sure that we are moving to right direction here. Thanks, -Maxim On 18/11/15 00:12, Jay Foad wrote: >>> Currently test/asan/TestCases/alloca_vla_interact.cc is XFAILed for >>> powerpc64. I've had a look at why it

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, I've been upgrading some custom LLVM passes to work with LLVM 2.6 instead of LLVM 2.5. I've noticed that in 2.6, some functions seem to have several local values with no name (where getName() returns an empty string). I never saw this in 2.5. Is this a known change in behaviour? Is there some handy way to get unique, deterministic names assigned to all values in a function? Thanks,

I'm trying to run some of the test suite using the instructions here: http://llvm.org/docs/TestingGuide.html#quicktestsuite I've built llvm myself, but I'm using pre-built binaries of llvm-gcc (from http://llvm.org/prereleases/2.5/llvm-gcc4.2-2.5-x86-linux-RHEL4.tar.gz). Here's what happens: foad at debian:~/svn/llvm-project/test-suite/trunk$ ./configure

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

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 >

Hi! Sorry for delay, just returned from vacation. On 12/11/15 23:44, Kostya Serebryany via llvm-dev wrote: > +Maxim and Yuri, as I think this is their code. > > On Thu, Nov 12, 2015 at 3:02 AM, Jay Foad <jay.foad at gmail.com > <mailto:jay.foad at gmail.com>> wrote: > > (Resending with the correct mailing list address.) > > Hi, > > Currently

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

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 >

> 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 they use implicitly defined structs for various ObjC runtime data structures; the ASTConsumer