similar to: [LLVMdev] [RC1] Status of Visual Studio 8, 9 and 10

They are good. I am checking with Release now. 20> Clang :: CodeGenObjC/image-info.m I will investigate it later. ...Takumi vs8 20>Failing Tests (3): 20> Clang :: CodeGenObjC/image-info.m 20> LLVM :: Transforms/SRETPromotion/basictest.ll 20> LLVM-Unit :: support/debug/SupportTests.exe/CastingTest.cast 20> Expected Passes : 8106 20> Expected Failures : 73

They are good. On VS9, it seems ARM stuff has been broken for months. ...Takumi vs8 10>-- Testing: 8725 tests, 8 threads -- 10>Testing Time: 245.20s 10> Expected Passes : 8100 10> Expected Failures : 73 10> Unsupported Tests : 552 vs9 10>Failing Tests (3): 10> LLVM :: CodeGen/ARM/bfi.ll 10> LLVM :: CodeGen/ARM/va_arg.ll 10> LLVM ::

2012/10/12 Emilien Kia <kiae.dev at gmail.com> > Hi guys, > Hi Emilien and the list, This is a pull request to finally merge NSS feature in nut trunk: > https://github.com/clepple/nut/pull/3 > I'd like to take a moment to shed some more light on this important development, which lasted 3 years: - the initial

On Thu, Jun 10, 2010 at 2:41 AM, Bigcheese <bigcheesegs at gmail.com> wrote: > On Wed, Jun 9, 2010 at 11:11 PM, Nathan Jeffords > <blunted2night at gmail.com> wrote: >> This is cool, I was looking into something like this, but hit a little bit >> of a wall, and then got sidetracked on another project. I was going to use >> llc to generate COFF object files

On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev < cfe-dev at lists.llvm.org> wrote: > SuSE Linux Enterprise Server 11SP3 x86_64 > > Looks like I see several failures that weren't in 3.7.1. Is there any way > to tell whether these are regressions vs new-to-3.8.0-but-failing? The > MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were > not

Sometime this week, the following test started failing: FAIL: LLVM-Unit :: Support/Release+Asserts/SupportTests/ErrorOr.Comparison (21978 of 22229) ******************** TEST 'LLVM-Unit :: Support/Release+Asserts/SupportTests/ErrorOr.Comparison' FAILED ******************** Note: Google Test filter = ErrorOr.Comparison [==========] Running 1 test from 1 test case. [----------] Global test

Hi, The attached patch removes sretpromotion from docs/Passes.html The sretpromotion pass got removed in version 3.0 Cheers, Stephan -------------- next part -------------- A non-text attachment was scrubbed... Name: Passes.html.patch Type: text/x-patch Size: 1904 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121122/11cd69f9/attachment.bin>

Here's the failing tests for rc2 on SLES11.3 (glibc 2.11, libstdc++4.7). I've done some amount of triaging what some critical elements of the failures are. Unabridged log is attached. Failing Tests (94): LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestAsyncIntInt LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestAsyncVoidBool LLVM-Unit ::

On Sep 15, 2009, at 8:32 AM, Kenneth Uildriks wrote: > In the latest snapshot from SVN on X86, llc refuses to compile > functions returning structs larger than two i32 members. > > According to the docs, such limitations can be expected to exist on > other platforms. > > This leads to a number of questions and observations: > > 1. Is there a good way to retrieve the

In the latest snapshot from SVN on X86, llc refuses to compile functions returning structs larger than two i32 members. According to the docs, such limitations can be expected to exist on other platforms. This leads to a number of questions and observations: 1. Is there a good way to retrieve the current target limitations on struct return sizes? 2. The sretpromotion pass does not take struct

On Tue, Sep 15, 2009 at 11:55 AM, Dan Gohman <gohman at apple.com> wrote: > > On Sep 15, 2009, at 8:32 AM, Kenneth Uildriks wrote: > >> In the latest snapshot from SVN on X86, llc refuses to compile >> functions returning structs larger than two i32 members. >> >> According to the docs, such limitations can be expected to exist on >> other platforms.

Hi Dan, > The requirement to update all callers' call instructions when a callee > gets a new return value is also present in the current MRV-mechanism > with getresult. It's not been a problem we've worried about so far. I didn't mean you can get away without updating your calllers, I'm just saying it could be a bit easier. > Can you give some background about

Hi, I found that building LLVM in single-threaded mode with CMake is failing because some object files still have references to pthread routines. There are two instances of the build failure happening. $ cmake .../llvm/ -DLLVM_ENABLE_THREADS=0 $ make -j8 check-all % Linking CXX executable IRTests ../../lib/libgtest.a(gtest.cc.o): In function

>Your "make check" output has two classes of errors: >1. llvm-gcc or llvm-g++ not being found. Its possible this results from >Cygwin requiring the .exe extension. The makefiles probably need to be >enhanced to include the suffix. Okay, but that did not seem to be a problem before. I thought about that being a possible problem. The make install removes the .exe

On Mon, 21 Jun 2004, Vladimir Merzliakov wrote: > Is it ok sending this results for FreeBSD5.1 at daily/weekly based to this > mail list? A better list for it would be the llvmbugs list for now. I beginning to think that we need a new test results mailing list. We have 3 instances of the nightly tester going now (x86/linux, sparc, ppc) and may have more in the future. The nightly tester

I'm having a problem with test/BugPoint/misopt-basictest.ll. I'm running it on a machine where gcc defaults to compiling 64-bit executables. When this test is executed, the code emitted by llc is 32-bit. So when gcc goes to compile it, it errors out because it's expected 64-bit assembly. My question is, is it okay to run this test with "-run-llc"? -bw

Kenneth Uildriks wrote: > On Tue, Sep 15, 2009 at 11:55 AM, Dan Gohman <gohman at apple.com> wrote: > >> On Sep 15, 2009, at 8:32 AM, Kenneth Uildriks wrote: >> >> >>> In the latest snapshot from SVN on X86, llc refuses to compile >>> functions returning structs larger than two i32 members. >>> >>> According to the docs,

Is it ok sending this results for FreeBSD5.1 at daily/weekly based to this mail list? Now results. Big improvement in llvm tests results from last test result sended. New regressions: Regression.Assembler.ConstantExprFold : FAIL , expected PASS Regression.CodeGen.Generic.2004-04-09-SameValueCoalescing: FAIL , expected PASS Regression.Transforms.PRE.basictest : FAIL

On Jun 2, 2008, at 8:45 AM, Matthijs Kooijman wrote: > Hi Dan, > >> Yes, the intention is that getresult will be removed once first-class >> aggregates are a ready replacement. This won't leave LLVM missing the >> concept of returning multiple values; a struct can be thought of as >> a container for multiple values. > I'm not saying we don't have some

Hi Dan, > Yes, the intention is that getresult will be removed once first-class > aggregates are a ready replacement. This won't leave LLVM missing the > concept of returning multiple values; a struct can be thought of as > a container for multiple values. I'm not saying we don't have some way of modeling multiple return values, I'm sayin the explicit concept