similar to: [LLVMdev] [RC3] Visual Studio [8,9,10] Debug build

Good evening, guys! At first, I apologize my report is a little gross, I have so little time to do checking process minutely. * RC1 RC1 can be built on VS8, 9, 10 with Debug|Release. At one point, r127264(in release_29/trunk) is needed to build with Debug on VS10. RC1 can pass clang-test with any configurations. RC1 fails llvm's check on many tests. * RC1 and patches ToT would be ready

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 ::

On Apr 5, 2013, at 9:19 PM, Jonathan wrote: > I got the following compile error. Did the message-arrays.m can be compiled into .bc? Or need include something for Object C language compile. Those are warnings, not errors. They otherwise compiled just fine. You should have a bitcode file named '1.ll' from each of those commands. Chip > > Jonathan > >

I got the following compile error. Did the message-arrays.m can be compiled into .bc? Or need include something for Object C language compile. Jonathan 118-165-76-229:CodeGenObjC Jonathan$ pwd /Users/Jonathan/llvm/release/src/tools/clang/test/CodeGenObjC 118-165-76-229:CodeGenObjC Jonathan$ clang -emit-llvm -o 1.ll -c message-arrays.m message-arrays.m:5:3: warning: instance method

I downloaded current version of FLAC sources and compiled it with: * GCC 4.8.1 (MSYS from http://xhmikosr.1f0.de/tools/) * Intel C++ Composer XE 2013 update 5 * MSVS 2010 SP1 * MSVS 2012 update 3 (SSSE3 and SSE4.1 code was disabled for all compilers) Stereo 24-bit WAV file was encoded with -8 preset. Encoding time, in seconds: GCC 32-bit: 209 ICC 32-bit: 130 VS10 32-bit: 116 VS12 32-bit: 114

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 ::

Look up --emit-llvm. I think it has to be used with -c. On Apr 5, 2013 10:55 PM, "Jonathan" <gamma_chen at yahoo.com.tw> wrote: > Following came from tools/clang/test/CodeGenObjC/message-arrays.m. But I > don't know how to compile it at terminal command since no clang_cc1 > executable file. Can some one help me? I am writing the llvm backend > document

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

Following came from tools/clang/test/CodeGenObjC/message-arrays.m. But I don't know how to compile it at terminal command since no clang_cc1 executable file. Can some one help me? I am writing the llvm backend document --http://jonathan2251.github.com/lbd/index.html now. I use "clang -c hello.cpp -emit-llvm" to compile C++ but don't know how to compile Object-C. // RUN:

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

Hi, I've bootstrapped llvm/clang from svn-trunk on powerpc-darwin8 (g++-4.0.1), and have the following test results to share. Summary below, full log at: http://www.csl.cornell.edu/~fang/sw/llvm/r146586-powerpc-darwin8-results.txt The only edits required were those I posted to llvm-commits yesterday (re: "some missing clang libs"). And I also edited LitConfig.py to point to