Re: [lldb-dev] [3.8 Release] Schedule and call for testers

2015-12-14 Thread Nikola Smiljanic via lldb-dev 
I'll do Fedora and openSUSE.

On Mon, Dec 14, 2015 at 9:08 PM, Daniel Sanders 
wrote:

> Sounds good to me. I'll do the usual mips packages.
>
> > -Original Message-
> > From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf
> > Of Hans Wennborg
> > Sent: 11 December 2015 23:15
> > To: llvm-dev; cfe-dev; lldb-dev@lists.llvm.org;
> openmp-...@lists.llvm.org
> > Cc: Dimitry Andric; Sebastian Dreßler; Renato Golin; Pavel Labath;
> Sylvestre
> > Ledru; Ed Maste; Ben Pope; Daniel Sanders; Nikola Smiljanić; Brian Cain;
> Tom
> > Stellard
> > Subject: [3.8 Release] Schedule and call for testers
> >
> > Dear everyone,
> >
> > It's not quite time to start the 3.8 release process, but it's time to
> > start planning.
> >
> > Please let me know if you want to help with testing and building
> > release binaries for your favourite platform. (If you were a tester on
> > the previous release, you're cc'd on this email.)
> >
> > I propose the following schedule for the 3.8 release:
> >
> > - 13 January: Create 3.8 branch. Testing Phase 1: RC1 binaries built
> > and tested, bugs fixed. Any almost-complete features need to be
> > wrapped up or disabled on the branch ASAP, and definitely before this
> > phase ends.
> >
> > - 27 January: Testing Phase 2: RC2 binaries built and tested. Only
> > critical bug fixes from now on. Further RCs published as we approach..
> >
> > - 18 February: Cut the final release, build binaries, ship when ready.
> >
> > Unless there are any objections, I'll post this on the web page.
> >
> > Cheers,
> > Hans
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [3.8 Release] RC1 has been tagged

2016-01-22 Thread Nikola Smiljanic via lldb-dev 
Something is failing on 32bit Fedora 23 (compiler-rt?), test suite looks
good.

On Fri, Jan 22, 2016 at 2:52 PM, Brian Cain via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> On Thu, Jan 21, 2016 at 8:31 PM, Eric Fiselier  wrote:
>
>>
>> On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev <
>> cfe-...@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 in 3.7.1.
>>>
>>>
>> All of the libc++ failures seem like non-issues and should be in 3.7.1.
>> Did you change or upgrade your platform or libc version?  I'm not sure
>> about the libc++abi error though.
>>
>
> I don't recall any changes to libc.  Attached is the testing log from
> 3.7.1 rc2 (I don't have logs from -final handy).
>
> I can repeat a 3.7.1 release build on this system now.  I don't think the
> results will change, though.
>
>
>
>> 
>>> Failing Tests (27):
>>> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.Async
>>> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrier
>>> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrierArgs
>>> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.GetFuture
>>> LLVM-Unit :: Support/SupportTests/ThreadPoolTest.PoolDestruction
>>> MemorySanitizer :: Linux/obstack.cc
>>> MemorySanitizer :: Linux/process_vm_readv.cc
>>> MemorySanitizer :: fork.cc
>>> MemorySanitizer :: iconv.cc
>>> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.fgetgrent_r
>>> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent
>>> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent_r
>>> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent
>>> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent_r
>>> MemorySanitizer-Unit ::
>>> Msan-x86_64-with-call-Test/MemorySanitizer.fgetgrent_r
>>> MemorySanitizer-Unit ::
>>> Msan-x86_64-with-call-Test/MemorySanitizer.getgrent
>>> MemorySanitizer-Unit ::
>>> Msan-x86_64-with-call-Test/MemorySanitizer.getgrent_r
>>> MemorySanitizer-Unit ::
>>> Msan-x86_64-with-call-Test/MemorySanitizer.getpwent
>>> MemorySanitizer-Unit ::
>>> Msan-x86_64-with-call-Test/MemorySanitizer.getpwent_r
>>> SanitizerCommon-Unit ::
>>> Sanitizer-x86_64-Test/SanitizerLinux.ThreadDescriptorSize
>>> ThreadSanitizer :: Linux/mutex_robust.cc
>>> ThreadSanitizer :: Linux/mutex_robust2.cc
>>> ThreadSanitizer :: thread_name2.cc
>>> libc++ :: std/depr/depr.c.headers/uchar_h.pass.cpp
>>>
>>
>> This is caused because the system does not provide a uchar.h header.
>>
>>
>>> libc++ ::
>>> std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname.pass.cpp
>>> libc++ ::
>>> std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname_wide.pass.cpp
>>>
>>
>>
>> These are marked XFAIL on open-suse, They should probably be marked as
>> XFAIL on your platform as well.
>> Can you send me the output of Python's "platform.linux_distribution()"?
>>
>>
>
> Ok, I'll be able to get this tomorrow.  But I suspect it will be "('SUSE
> Linux Enterprise Server ', '11', 'x86_64')"
>
>
>> libc++abi :: cxa_thread_atexit_test.pass.cpp
>>>
>>
>> Not sure about this failure. Can you send me the output?
>>
>>
> That one failed in 3.7.1 also.  IIRC this libstdc++ doesn't have
> cxa_thread_atexit.
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
[  1%] Built target LLVMTableGen
[  1%] Built target gtest_main
[  1%] Built target gtest
[  1%] Built target LLVMMCParser
[  1%] Built target LLVMMCDisassembler
[  1%] Built target obj.llvm-tblgen
[  2%] Built target LLVMDebugInfoDWARF
[  5%] Built target LLVMSupport
[  5%] Built target LLVMLineEditor
[  5%] Built target LLVMOption
[  6%] Built target LLVMDebugInfoPDB
[  9%] Built target LLVMMC
Scanning dependencies of target SanitizerLintCheck
[  9%] Built target LLVMHello_exports
[  9%] Built target count
[  9%] Built target compiler-rt-headers
[  9%] Running lint check for sanitizer sources...
[ 10%] Built target cxxabi_objects
[ 10%] Built target RTUbsan_standalone.i386
[ 11%] Built target obj.clang-tblgen
[ 11%] Built target RTUbsan.i386
[ 11%] Built target RTSanitizerCommonLibc.i386
[ 12%] Built target RTUbsan_cxx.i386
[ 13%] Built target RTSanitizerCommon.i386
[ 13%] Built target RTAsan_preinit.i386
[ 13%] Built target RTAsan_dynamic_version_script_dummy.i386
[ 13%] Built target asan_blacklist
[ 13%] Built target RTInterception.i386
[ 13%] Built target RTLSanCommon.i386
[ 13%] Built target RTAsan_cxx.i386
[ 13%] Built target RTSanitizerCommonNoLibc.i386
[ 14%] Built target clang_rt.profile-i386
[ 16%]

Re: [lldb-dev] [cfe-dev] [3.8 Release] RC1 has been tagged

2016-01-23 Thread Nikola Smiljanic via lldb-dev 
Two libc++ tests fail on 64bit Fedora 23, get_monthname and
get_monthname_wide. Test suite looks good.

On Fri, Jan 22, 2016 at 10:09 PM, Nikola Smiljanic 
wrote:

> Something is failing on 32bit Fedora 23 (compiler-rt?), test suite looks
> good.
>
> On Fri, Jan 22, 2016 at 2:52 PM, Brian Cain via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> On Thu, Jan 21, 2016 at 8:31 PM, Eric Fiselier  wrote:
>>
>>>
>>> On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev <
>>> cfe-...@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 in 3.7.1.


>>> All of the libc++ failures seem like non-issues and should be in 3.7.1.
>>> Did you change or upgrade your platform or libc version?  I'm not sure
>>> about the libc++abi error though.
>>>
>>
>> I don't recall any changes to libc.  Attached is the testing log from
>> 3.7.1 rc2 (I don't have logs from -final handy).
>>
>> I can repeat a 3.7.1 release build on this system now.  I don't think the
>> results will change, though.
>>
>>
>>
>>> 
 Failing Tests (27):
 LLVM-Unit :: Support/SupportTests/ThreadPoolTest.Async
 LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrier
 LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrierArgs
 LLVM-Unit :: Support/SupportTests/ThreadPoolTest.GetFuture
 LLVM-Unit :: Support/SupportTests/ThreadPoolTest.PoolDestruction
 MemorySanitizer :: Linux/obstack.cc
 MemorySanitizer :: Linux/process_vm_readv.cc
 MemorySanitizer :: fork.cc
 MemorySanitizer :: iconv.cc
 MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.fgetgrent_r
 MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent
 MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent_r
 MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent
 MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent_r
 MemorySanitizer-Unit ::
 Msan-x86_64-with-call-Test/MemorySanitizer.fgetgrent_r
 MemorySanitizer-Unit ::
 Msan-x86_64-with-call-Test/MemorySanitizer.getgrent
 MemorySanitizer-Unit ::
 Msan-x86_64-with-call-Test/MemorySanitizer.getgrent_r
 MemorySanitizer-Unit ::
 Msan-x86_64-with-call-Test/MemorySanitizer.getpwent
 MemorySanitizer-Unit ::
 Msan-x86_64-with-call-Test/MemorySanitizer.getpwent_r
 SanitizerCommon-Unit ::
 Sanitizer-x86_64-Test/SanitizerLinux.ThreadDescriptorSize
 ThreadSanitizer :: Linux/mutex_robust.cc
 ThreadSanitizer :: Linux/mutex_robust2.cc
 ThreadSanitizer :: thread_name2.cc
 libc++ :: std/depr/depr.c.headers/uchar_h.pass.cpp

>>>
>>> This is caused because the system does not provide a uchar.h header.
>>>
>>>
 libc++ ::
 std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname.pass.cpp
 libc++ ::
 std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname_wide.pass.cpp

>>>
>>>
>>> These are marked XFAIL on open-suse, They should probably be marked as
>>> XFAIL on your platform as well.
>>> Can you send me the output of Python's "platform.linux_distribution()"?
>>>
>>>
>>
>> Ok, I'll be able to get this tomorrow.  But I suspect it will be "('SUSE
>> Linux Enterprise Server ', '11', 'x86_64')"
>>
>>
>>> libc++abi :: cxa_thread_atexit_test.pass.cpp

>>>
>>> Not sure about this failure. Can you send me the output?
>>>
>>>
>> That one failed in 3.7.1 also.  IIRC this libstdc++ doesn't have
>> cxa_thread_atexit.
>>
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] [3.8 Release] RC1 has been tagged

2016-01-27 Thread Nikola Smiljanic via lldb-dev 
It seems that test-release was fixed, thanks everyone. Builds are OK but
I'd like to know where did test-suite go? All I see is the llvm.src
directory, am I supposed to export test-suite myself?

On Wed, Jan 27, 2016 at 9:47 PM, Daniel Sanders 
wrote:

> > Have you accidentally checked out the test-suite into /projects? if it's
> there it will auto-configure
>
>
>
> We fixed it for rc1 but test-release.sh used to put the test-suite there.
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] *On Behalf Of *James
> Molloy via llvm-dev
> *Sent:* 26 January 2016 16:05
> *To:* Ismail Donmez; Nikola Smiljanic
> *Cc:* Ben Pope; llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org);
> LLDB Dev
> *Subject:* Re: [llvm-dev] [cfe-dev] [3.8 Release] RC1 has been tagged
>
>
>
> The test-suite shouldn't be being build with CMake for the release - the
> CMake system is not yet ready. Have you accidentally checked out the
> test-suite into /projects? if it's there it will auto-configure.
>
>
>
> James
>
>
>
> On Tue, 26 Jan 2016 at 16:01 Ismail Donmez via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
> On Tue, Jan 26, 2016 at 1:56 PM, Nikola Smiljanic via llvm-dev
>  wrote:
> > Phase1 fails to build on openSUSE 13.2, can anyone see what's wrong from
> > this log file?
>
> Something wrong with the test-suite:
>
> make -f CMakeFiles/test-suite.dir/build.make
> CMakeFiles/test-suite.dir/depend
> make[2]: Entering directory
> '/home/nikola/rc1/Phase1/Release/llvmCore-3.8.0-rc1.obj'
> CMakeFiles/test-suite.dir/build.make:112: *** target pattern contains
> no '%'.  Stop.
> make[2]: Leaving directory
> '/home/nikola/rc1/Phase1/Release/llvmCore-3.8.0-rc1.obj'
> CMakeFiles/Makefile2:198: recipe for target
> 'CMakeFiles/test-suite.dir/all' failed
> make[1]: *** [CMakeFiles/test-suite.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [3.8 Release] RC2 has been tagged

2016-02-05 Thread Nikola Smiljanic via lldb-dev 
Fedora looks OK, openSUSE not so much, check gets stuck at 90% on x64 but
test suite passes OK, on x86 build succeeds but test suite fails saying
'import spec' no module found.

On Fri, Feb 5, 2016 at 9:50 PM, Daniel Sanders via Release-testers <
release-test...@lists.llvm.org> wrote:

> Here's the status for my builds so far.
>
> clang+llvm-3.8.0-rc2-x86_64-linux-gnu-debian8.tar.xz (sha1sum:
> 2b546efa5bab19d6711771ef31711d07b4a3f23f)
> Native:
> All ok
> Cross compiling to various MIPS targets:
> 16 out of 23 configs passed
> 1 out of the remaining 7 failed a small number of tests
> with a timeout. I expect these will pass when I re-run them.
> Remaining 6 configs still running...
>
> clang+llvm-3.8.0-rc2-mips-linux-gnu.tar.xz (sha1sum:
> b46221e1bb54255e9e060f06bb72bb2ba630ff15)
> Failed to run check-all due to tsan'd libc++ build failing
> PR26278 - My fix for this was committed just after the rc2
> tag so in order to get some check-all results, I applied those four patches
> (r25966[1456]) and re-ran check-all.
> PR26369 - Several failures related to the lack of -latomic
> which is needed for 64-bit atomics.
> PR26476 - One new failure in libc++ (I probably just
> missed it amongst the others). Apparently std::regex_traits says that '-'
> doesn't belong to the 'w' class but only on big-endian.
> check-all appears to hang at 99%. I'll look into this.
> LNT (using the clean rc2)
> 1 of 3 passed successfully, the other two are still running
>
> clang+llvm-3.8.0-rc2-mipsel-linux-gnu.tar.xz (sha1sum:
> 9f89cccfdb5cf6a27138b84a631003c4a04f456d)
> Build almost ok. I only have failures related to PR26369.
> LNT just started.
>
> > -Original Message-
> > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
> Hans
> > Wennborg via lldb-dev
> > Sent: 02 February 2016 21:16
> > To: release-test...@lists.llvm.org
> > Cc: llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev
> > Subject: [lldb-dev] [3.8 Release] RC2 has been tagged
> >
> > Dear testers,
> >
> > Release Candidate 2 has just been tagged [1]. Please build, test, and
> > upload to the sftp.
> >
> > I know there are still outstanding issues from RC1, but there have
> > been a lot of merges going into the branch and I think it's time for
> > another round of RC testing.
> >
> > This RC comes a little behind schedule, sorry about that, but I'm
> > still optimistic about hitting the target of releasing towards the end
> > of February.
> >
> > Thanks for all the work you've put into this release so far!
> >
> > Hans
> >
> >  [1] http://lists.llvm.org/pipermail/llvm-branch-commits/2016-
> > February/009739.html
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [3.8 Release] RC3 has been tagged

2016-02-25 Thread Nikola Smiljanic via lldb-dev 
Uploaded Fedora and openSUSE binaries. Looking good.

On Thu, Feb 25, 2016 at 4:11 PM, Ben Pope via Release-testers <
release-test...@lists.llvm.org> wrote:

> On Wednesday, February 24, 2016 05:51 AM, Hans Wennborg via
> Release-testers wrote:
>
>> Dear testers,
>>
>> Release Candidate 3 has just been tagged [1]. Please build, test, and
>> upload to the sftp.
>>
> Uploaded:
> clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-16.04.tar.xz
> clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-15.10.tar.xz
> clang+llvm-3.8.0-rc3-x86_64-linux-gnu-ubuntu-14.04.tar.xz
>
> On Ubuntu 16.04 x86_64:
>
> Failing Tests (7):
> MemorySanitizer :: Linux/forkpty.cc
> MemorySanitizer :: Linux/tcgetattr.cc
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r
> MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getmntent
> MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r
> Profile :: instrprof-error.c
>
>   Expected Passes: 31128
>   Expected Failures  : 172
>   Unsupported Tests  : 615
>   Unexpected Failures: 7
>
>
> On Ubuntu 15.10 x86_64:
>
> Failing Tests (2):
> MemorySanitizer :: Linux/forkpty.cc
> MemorySanitizer :: Linux/tcgetattr.cc
>
>   Expected Passes: 31860
>   Expected Failures  : 209
>   Unsupported Tests  : 648
>   Unexpected Failures: 2
>
>
> On Ubuntu 14.04 x86_64:
>
> Failing Tests (9):
> MemorySanitizer :: Linux/forkpty.cc
> MemorySanitizer :: Linux/tcgetattr.cc
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r
> MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getmntent
> MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r
> Profile :: instrprof-error.c
> libc++ ::
> std/localization/locale.categories/category.ctype/locale.ctype.byname/types.pass.cpp
> libc++ ::
> std/localization/locales/locale/locale.cons/char_pointer.pass.cpp
>
>   Expected Passes: 31194
>   Expected Failures  : 195
>   Unsupported Tests  : 526
>   Unexpected Failures: 9
>
> LNT results look good, although they are, perhaps 20% slower than most of
> my previous runs.
>
> Ben
>
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [3.8 Release] 'final' has been tagged

2016-03-04 Thread Nikola Smiljanic via lldb-dev 
Uploaded Fedora and openSUSE binaries

5bc4bb9b1cadb37567328430c87e958b916049d8
 clang+llvm-3.8.0-i586-opensuse13.2.tar.xz
76d64a4cec71b95263bdf9b46bb3367f4b747c53
 clang+llvm-3.8.0-i686-fedora23.tar.xz
716d09d8d27f715ffcd795a138184033f83a7703
 clang+llvm-3.8.0-x86_64-fedora23.tar.xz
3f68b54a7c9be391c8908b0bb2d67e7a87107dc4
 clang+llvm-3.8.0-x86_64-opensuse13.2.tar.xz

On Fri, Mar 4, 2016 at 12:07 PM, Brian Cain via Release-testers <
release-test...@lists.llvm.org> wrote:

>
>
> On Wed, Mar 2, 2016 at 6:33 PM, Hans Wennborg via Release-testers <
> release-test...@lists.llvm.org> wrote:
>
>> Dear testers,
>>
>> My list of blockers is empty, and there were no new problems
>> discovered with rc3, so I have gone ahead and tagged 3.8.0-final [1].
>>
>> Please build the final binaries and upload to the sftp.
>>
>> For others following along: yes, this means 3.8.0 is complete, but it
>> takes a couple of days to get the source and binary tarballs built. I
>> will send the release announcement when everything's ready.
>>
>>
>>
> Uploaded clang+llvm-3.8.0-x86_64-sles11.3-linux-gnu.tar.xz
> and clang+llvm-3.8.0-linux-armhf-vivid.tar.xz
>
> 7388c9ec1c9680a3366dd40e0bb8acc655b3e3ec
>  clang+llvm-3.8.0-linux-armhf-vivid.tar.xz
> c33ab986d5b8dce7af88ca1b748240f98c4ed2c5
>  clang+llvm-3.8.0-x86_64-sles11.3-linux-gnu.tar.xz
>
>
>
>
> --
> -Brian
>
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up

2015-08-21 Thread Nikola Smiljanic via lldb-dev 
Hi Dmitry, if I understood Hans clang-extra wasn't part of the build prior
to rc3. Just delete it and run script with --no-checkout.

On Fri, Aug 21, 2015 at 7:15 PM, Dimitry Andric  wrote:

> Hm, it does not seem to compile at all here?  The build ends with:
>
> In file included from
> /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/ApplyReplacements.cpp:17:
> /home/dim/llvm-3.7.0/rc3/llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../include/clang-apply-replacements/Tooling/ApplyReplacements.h:19:10:
> fatal error: 'clang/Tooling/Refactoring.h' file not found
> #include "clang/Tooling/Refactoring.h"
>  ^
> 1 error generated.
>
> Any idea?  I had no problems at all with -rc2.
>
> -Dimitry
>
> > On 21 Aug 2015, at 02:51, Hans Wennborg  wrote:
> >
> > Hello everyone,
> >
> > 3.7-rc3 has just been tagged. Testers, please test, build binaries,
> > upload to the sftp and report results to this thread.
> >
> > Again, a lot of patches got merged between rc2 and rc3, but hopefully
> > nothing that should upset things.
> >
> > One thing that did change is that the release script now correctly
> > symlinks clang-tools-extra into the build. If this causes problems on
> > your platform, please just remove it.
> >
> > This is a release candidate in the real sense: at this point I have
> > zero release blockers on my radar. I will now only accept fixes for
> > critical regressions, and if nothing comes up, rc3 will be promoted to
> > 3.7.0-final.
> >
> > Documentation and release note patches are still welcome all the way
> > up until the final tag goes in.
> >
> > Issues that were on my radar, but I don't consider blocking:
> >
> > - Sanitizer test failures on various platforms, e.g. PR24222. We never
> > ran these tests in previous releases, so it's not a regression. It
> > would be great if the sanitizer folks could look into the test
> > failures, but it's not blocking 3.7.
> >
> > - PR24273: "[ARM] Libc++abi built in-tree with libunwind fails in
> > __cxa_allocate_exception", Renato will exclude libc++ from his build
> > for now.
> >
> > - Lack of key functions in some Instruction classes causing build
> > failures without -fno-rtti
> > (http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html). No
> > patches have been forthcoming, so this will not get fixed for 3.7. At
> > least we correctly report -fno-rtti in llvm-config built with CMake
> > now.
> >
> > - r244221: "[SPARC] Don't compare arch name as a string, use the enum
> > instead", owner is unresponsive.
> >
> > - "[lldb] r245020 - [MIPS]Handle floating point and aggregate return
> > types in SysV-mips [32 bit] ABI", owner is unresponsive.
> >
> >
> > Cheers,
> > Hans
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [3.7 Release] RC3 has been tagged, let's wrap this up

2015-08-22 Thread Nikola Smiljanic via lldb-dev 
Fedora and openSUSE uploaded.

On Sat, Aug 22, 2015 at 6:59 AM, Renato Golin 
wrote:

> AArch64 up. All green.
>
> On 21 August 2015 at 01:51, Hans Wennborg  wrote:
> > Hello everyone,
> >
> > 3.7-rc3 has just been tagged. Testers, please test, build binaries,
> > upload to the sftp and report results to this thread.
> >
> > Again, a lot of patches got merged between rc2 and rc3, but hopefully
> > nothing that should upset things.
> >
> > One thing that did change is that the release script now correctly
> > symlinks clang-tools-extra into the build. If this causes problems on
> > your platform, please just remove it.
> >
> > This is a release candidate in the real sense: at this point I have
> > zero release blockers on my radar. I will now only accept fixes for
> > critical regressions, and if nothing comes up, rc3 will be promoted to
> > 3.7.0-final.
> >
> > Documentation and release note patches are still welcome all the way
> > up until the final tag goes in.
> >
> > Issues that were on my radar, but I don't consider blocking:
> >
> > - Sanitizer test failures on various platforms, e.g. PR24222. We never
> > ran these tests in previous releases, so it's not a regression. It
> > would be great if the sanitizer folks could look into the test
> > failures, but it's not blocking 3.7.
> >
> > - PR24273: "[ARM] Libc++abi built in-tree with libunwind fails in
> > __cxa_allocate_exception", Renato will exclude libc++ from his build
> > for now.
> >
> > - Lack of key functions in some Instruction classes causing build
> > failures without -fno-rtti
> > (http://lists.llvm.org/pipermail/llvm-dev/2015-August/089010.html). No
> > patches have been forthcoming, so this will not get fixed for 3.7. At
> > least we correctly report -fno-rtti in llvm-config built with CMake
> > now.
> >
> > - r244221: "[SPARC] Don't compare arch name as a string, use the enum
> > instead", owner is unresponsive.
> >
> > - "[lldb] r245020 - [MIPS]Handle floating point and aggregate return
> > types in SysV-mips [32 bit] ABI", owner is unresponsive.
> >
> >
> > Cheers,
> > Hans
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [3.7 Release] 3.7.0-final has been tagged

2015-08-29 Thread Nikola Smiljanic via lldb-dev 
Uploaded:

70eff9d3bfc2361a440358cb46216383e562479e
 clang+llvm-3.7.0-i586-opensuse13.2.tar.xz
732cf3f91888b09d7c1bee475b7ba39032fcaa6b
 clang+llvm-3.7.0-i686-fedora22.tar.xz
390534a5a7b87b855285271be1dd3ecee17e3da8
 clang+llvm-3.7.0-x86_64-fedora22.tar.xz
c5cb2000d563511ba81ce86419eaa1bef64ab19f
 clang+llvm-3.7.0-x86_64-opensuse13.2.tar.xz


On Sat, Aug 29, 2015 at 5:34 AM, Dimitry Andric  wrote:

> On 28 Aug 2015, at 20:12, Hans Wennborg  wrote:
> >
> > On Thu, Aug 27, 2015 at 6:46 PM, Hans Wennborg 
> wrote:
> >> I have promoted RC4 to final; 3.7.0 has reached its final state.
> >>
> >> Thanks for all your hard work so far. Please build and upload binaries
> >> with "-final", and let's ship this next week!
> >
> > Windows binaries uploaded. sha1sums:
> >
> > 44400734e1cbe1cfef3fc3ea03d8cba31ee50e66  LLVM-3.7.0-win32.exe
> > 70aec264a5bfce1b5e596d93762e0481cb896a6b  LLVM-3.7.0-win64.exe
>
> No building or testing problems encountered on FreeBSD 10.  The only
> strange thing is that relative to -rc4, I now got a lot more "differs
> between phase 2 and phase 3" messages.  But this is probably due to turning
> off assertions.
>
> Uploaded:
>
> SHA256 (clang+llvm-3.7.0-i386-unknown-freebsd10.tar.xz) =
> 07cf94ddff7c4dff112eeadb95aab1b905cd40a3462c6afd808988164146d880
> SHA256 (clang+llvm-3.7.0-amd64-unknown-freebsd10.tar.xz) =
> fe8c7136d254a4a25967c4d8d97f48a985cb594fe5c864dc234526a6bacfebe2
>
> -Dimitry
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev