similar to: [LLVMdev] LLVM 3.4.1 Testing Phase Part 2

You're not the only one Hans, my VMs have started crashing my host OS :) Fedora and OpenSUSE look good, binaries uploaded. On Sat, Dec 13, 2014 at 12:06 PM, Hans Wennborg <hans at chromium.org> wrote: > > On Thu, Dec 11, 2014 at 5:26 PM, Tom Stellard <tom at stellard.net> wrote: > > Hi, > > > > 3.5.1-rc1 has been tagged, so it is time to begin testing. We

On Thursday, January 15, 2015 06:55 AM, Nikola Smiljanic wrote: > Was there an rc3 that I missed? > It's not tagged if there was. I've tested and uploaded 3.5.1 final for x86_64-ubuntu-14.04. I think the rc2 build required a newer libstdc++ than exists on Ubuntu 14.04, but the final build should be good. Ben

I've uploaded clang+llvm-3.5.1-rc2-mips-linux-gnu.tar.xz and clang+llvm-3.5.1-rc2-mipsel-linux-gnu.tar.xz. The latter fails prune.m in 'make check-all' as it did last time but this is because the 'touch -a' command isn't actually changing the access timestamp. I've started the test-suite for both of them. ________________________________________ From: llvmdev-bounces

On Tue, Dec 23, 2014 at 09:27:32PM +0000, Daniel Sanders wrote: > clang+llvm-3.5.1-rc2-mips-linux-gnu.tar.xz: > All ok for default options and -mips32. > > clang+llvm-3.5.1-rc2-mipsel-linux-gnu.tar.xz: > All ok for default options. > It will take a couple days to get results for the -mips32 test-suite (there's no FPU or local disk on this machine so some tests

Hi, I have just tagged the first release candidate for the 3.4.1 release, so testers may begin testing. Please refer to http://llvm.org/docs/ReleaseProcess.html for information on how to validate a release. If you have any questions or need something clarified, just email the list. For the 3.4.1 release we want to compare test results against 3.4-final. I have added support to the

Building phase 2 fails on i686 Fedora 22 CMake Error at projects/compiler-rt/cmake/config-ix.cmake:125 (message): Cannot compile for i686: CMakeError.log attached On Wed, Jul 22, 2015 at 8:20 AM, Alexey Samsonov <vonosmas at gmail.com> wrote: > The problem is we "guess" that the host architecture is i686, and fail > when we find out that we can't target it (__i686__

Hi, The only regression in 3.6.1 -rc1 was on MIPS and it has been confirmed fixed, so I have now tagged 3.6.1 -final. Testers can start building and uploading the final binaries. Thanks, Tom

> Test suite is green but I'm seeing two libc++ test failures when running check-all. What tests are failing? On Fri, Jun 10, 2016 at 5:13 PM, Nikola Smiljanic via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Uploaded Fedora and openSUSE binaries. Test suite is green but I'm seeing > two libc++ test failures when running check-all. I'm pretty sure these were >

On Tue, Sep 6, 2011 at 11:28 PM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > The problem is not in the functions that return multibyte strings (the > multibyte string is coming from argv) argv is implicitly the return from a UTF16->multibyte conversion (i.e. it's lossy). -Eli

Seems on OpenSUSE x86, it's called i586, not i686 :-( +Alexey: do you think we can handle this in the compiler-rt cmake files somehow? Maybe try targeting both i686 and i586 unless that would break something else? On Fri, Jul 17, 2015 at 1:31 AM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > CMake Error at projects/compiler-rt/cmake/config-ix.cmake:125 (message): > Cannot

On Wed, Sep 7, 2011 at 12:20 AM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > So what are you exactly saying? Somebody proposed using GetCommandLine > instead of using argv directly. And what about my other points about ::open > and ::stat? Because of the way Windows works, the only fully correct solution is to never touch the native charset, and keep everything in UTF-8/16

Hi, I had a quick look at that link and it seems to be a linker internal error. Presumably we're triggering a bug in the system toolchain. FWIW, my mipsel build on a Debian Jessie machine (binutils 2.24.90.20141023-1) successfully completed test-release.sh. I'm currently running the tests. Here's the relevant bit of the log from your link: cd

Final has been tagged, I think we're about to release it. On Fri, Feb 27, 2015 at 7:43 AM, Hayden Livingston <halivingston at gmail.com> wrote: > Are we waiting for an RC5? It seems like the release mirror on github has > no recent activity. > > On Wed, Feb 25, 2015 at 3:23 AM, Daniel Sanders <Daniel.Sanders at imgtec.com > > wrote: > >> Quick update

I still haven't finished but I don't think you have to wait. On Fri, Feb 27, 2015 at 7:46 AM, Renato Golin <renato.golin at linaro.org> wrote: > We got everything, haven't we? > > On 26 February 2015 at 20:44, Nikola Smiljanic <popizdeh at gmail.com> wrote: > > Final has been tagged, I think we're about to release it. > > > > On Fri, Feb 27,

So what are you exactly saying? Somebody proposed using GetCommandLine instead of using argv directly. And what about my other points about ::open and ::stat? On Wed, Sep 7, 2011 at 8:52 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Sep 6, 2011 at 11:28 PM, Nikola Smiljanic <popizdeh at gmail.com> > wrote: > > The problem is not in the functions that

What is the procedure now? Do we just wait for someone else to look at it and commit (I'm guessing that you don't have commit access)? cfe-commits is in the CC. On Tue, Oct 11, 2011 at 6:55 PM, Aaron Ballman <aaron at aaronballman.com>wrote: > Looks good to me! > > Thanks! > > ~Aaron > > On Tue, Oct 11, 2011 at 2:26 AM, Nikola Smiljanic <popizdeh at

We got everything, haven't we? On 26 February 2015 at 20:44, Nikola Smiljanic <popizdeh at gmail.com> wrote: > Final has been tagged, I think we're about to release it. > > On Fri, Feb 27, 2015 at 7:43 AM, Hayden Livingston <halivingston at gmail.com> > wrote: >> >> Are we waiting for an RC5? It seems like the release mirror on github has >> no

Nikola Smiljanic <popizdeh at gmail.com> writes: > I'm not sure if this makes a difference but I ran this > > make -j 2 -k LLVMCC_OPTION=clang ENABLE_BUILT_CLANG=1 ENABLE_PARALLEL_REPORT=1 TEST=simple report > ../../report.txt 2>&1 That does indeed seem to get me further. Thanks! -Dave

Hi, 3.5.1-rc1 has been tagged, so it is time to begin testing. We can always use more testers, so if you would like to volunteer, let me know. For those that are new to testing, please review the documentation for how validate a new release: http://llvm.org/docs/ReleaseProcess.html Remember that when we check for regressions we want to compare the test results of 3.5.1-rc1 with 3.5.0-final.

As was mentioned once before, the correct solution is to never use multibyte anywhere. Any Windows functions that currently return multibyte strings should be converted to their wide-string (unicode) equivalent, with the result converted to UTF-8. > From: Nikola Smiljanic <popizdeh at gmail.com> > > I think I got it this time. I realized that ::open and ::stat work just fine with