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

[Hans Wennborg via lldb-dev]

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

[lldb-dev] [3.8 Release] One week to the branch

[Hans Wennborg via lldb-dev]

Just a quick reminder: the branch point is coming up in one week, on 13 January.

Cheers,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.8 Release] We have branched

[Hans Wennborg via lldb-dev]

And so the release process begins.

The 3.8 branch was created today from trunk at r257626, and the trunk
version was then bumped to 3.9.

Release blockers are tracked by http://llvm.org/PR26059. If you find
any bugs (either new or already in the tracker) that you think need to
be fixed before the release, please mark them as blocking this bug.

To get a change committed on the branch, first commit it to trunk as
usual, then reply to the commit message on the mailing list with
myself and the appropriate code owner CC'd, asking for the change to
be merged to the branch.

Release notes for 3.8 should be committed directly to the branch, or
sent to me in an email and I'll do it for you. If you made any
non-trivial changes in the last six months (or know someone else who
did), please make sure they get mentioned in the notes.

Next up on the schedule is preparing the first release candidate
(RC1). This will happen in a few days, once the branch is known to be
in good shape.

The hardest part of releasing is staying on top of everything. Please
help me out by CC'ing me on any bugs, commits, or other issues that
are relevant for the release. If I'm not CC'd, there's a large chance
I will miss it.

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] We have branched

[Hans Wennborg via lldb-dev]

Hi Daniel,

Thanks for trying out the branch :-)

On Fri, Jan 15, 2016 at 5:30 AM, Daniel Sanders
 wrote:
> Hi Hans,
>
> I tried the release branch last night and I'm having problems building it. 
> The problem is that test-suite is now building as part of the Phase[123] 
> builds (because this project contains CMakeLists.txt's now) but cmake 3.0.2 
> (from Debian Jessie) generates an invalid Makefile.
> The error is:
> CMakeFiles/test-suite.dir/build.make:112: *** target pattern contains 
> no '%'.  Stop.
> CMakeFiles/Makefile2:199: recipe for target 
> 'CMakeFiles/test-suite.dir/all' failed
> And the referenced line of the generated makefile is:
> test-suite-stamps/test-suite-force-rebuild: 
> /home/das-local/llvm-release-3.8/release/branches_release_38/llvm.src/$
> it looks like cmake isn't fully expanding its generator expressions.
>
> Looking at my logs, it looks like the test-suite used to configure in 3.6.2 
> but didn't build as part of test-release.sh and then 3.7.0 stopped since we 
> had switched to cmake and there was no CMakeLists.txt.
> I've always run the test-suite as a separate step as described in 
> http://llvm.org/docs/ReleaseProcess.html. Should we stop creating the 
> projects/test-suite symlink to get back to the behaviour from 3.7.0 or should 
> we do something else?

Yes, I made the script stop making the symlink in r257791 and merged
it to the branch. Did that not work for you, or were you at an earlier
revision?

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.8 Release] RC1 has been tagged

[Hans Wennborg via lldb-dev]

Dear testers,

Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
r258223. (It took a little longer than I'd planned, sorry about that.)

There are still a bunch of open merge requests and bug reports, but I
wanted to get the tag in so we can see what the build and test status
are on the various platforms.

I verified that it currently builds and tests cleanly for me on x86_64
Linux, Mac OS X* and Windows.

Please build, test, and upload binaries to the sftp. Let me know if how it goes.

Thanks,
Hans


[*] For Mac, I had to set CFLAGS="-isysroot `xcrun -show-sdk-path`"
CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build to work,
otherwise stage-2 Clang couldn't find the SDK. I don't remember if I
had to do this last time; maybe some upgrade changed something.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

(cc'ing non-legacy llvm-dev this time; apologies if you get this
twice. Please don't reply-all to the first one.)

On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg  wrote:
> Dear testers,
>
> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
> r258223. (It took a little longer than I'd planned, sorry about that.)
>
> There are still a bunch of open merge requests and bug reports, but I
> wanted to get the tag in so we can see what the build and test status
> are on the various platforms.
>
> I verified that it currently builds and tests cleanly for me on x86_64
> Linux, Mac OS X* and Windows.
>
> Please build, test, and upload binaries to the sftp. Let me know if how it 
> goes.
>
> Thanks,
> Hans
>
>
> [*] For Mac, I had to set CFLAGS="-isysroot `xcrun -show-sdk-path`"
> CXXFLAGS="-isysroot `xcrun -show-sdk-path`" for the build to work,
> otherwise stage-2 Clang couldn't find the SDK. I don't remember if I
> had to do this last time; maybe some upgrade changed something.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

That would certainly make my emails easier to address :-) On the other
hand, I do think there's a point to asking for testers each time and
then only addressing those that sign up explicitly. What do the rest
of you think about having a list?

On Wed, Jan 20, 2016 at 1:31 AM, Sylvestre Ledru  wrote:
> What about creating a release management mailing list ?
> The testers are usually the same (hello folks!) :)
>
> Sylvestre
>
> Le 20/01/2016 00:55, Hans Wennborg a écrit :
>> (cc'ing non-legacy llvm-dev this time; apologies if you get this
>> twice. Please don't reply-all to the first one.)
>>
>> On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg  wrote:
>>> Dear testers,
>>>
>>> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
>>> r258223. (It took a little longer than I'd planned, sorry about that.)
___
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

[Hans Wennborg via lldb-dev]

On Wed, Jan 20, 2016 at 2:15 AM, Ismail Donmez  wrote:
> On Wed, Jan 20, 2016 at 1:47 AM, Hans Wennborg via cfe-dev
>  wrote:
>> Dear testers,
>>
>> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
>> r258223. (It took a little longer than I'd planned, sorry about that.)
>>
>> There are still a bunch of open merge requests and bug reports, but I
>> wanted to get the tag in so we can see what the build and test status
>> are on the various platforms.
>>
>> I verified that it currently builds and tests cleanly for me on x86_64
>> Linux, Mac OS X* and Windows.
>
> Doesn't looks good here, stage2 build crashes:

:-(

Can you file a bug with the preprocessed source and invocation attached?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

On Wed, Jan 20, 2016 at 5:25 AM, Dimitry Andric  wrote:
> Unfortunately I'm having lots of trouble with rc1 at this point:
> * libcxxabi can't build, because it requires unwind.h, which we do not yet 
> have on FreeBSD 10.x (Ed Maste is working on it for 11.x, but that is not 
> ready for general consumption).
> * The test-release.sh script has no option to disable only libcxxabi, you can 
> only disable libcxx, libcxxabi and libunwind together (maybe this can be 
> improved)

Yes, I'd be happy to take a patch for this, or I suppose you could
just hack it out locally when building.

> * Last time I hand-built libcxx, it still had a lot of test failures in the 
> locale parts, but I haven't had time to investigate.

Did we have that for 3.7 too?

> * OpenMP does not support i386-freebsd, so I have to disable it there

That's perfectly fine. Including OpenMP by default is new for this
release, so if it causes any problems, just exclude it.

> * Last but not least: the host compiler on FreeBSD 10.x is clang 3.4.1 (the 
> last version that can build without C++11 support), and it crashes with a 
> segfault during building of CGBlocks.cpp.  I'll need to find some way to work 
> around this failure, since we cannot upgrade the compiler easily on FreeBSD 
> 10.x.

This sounds like the biggest problem. Is there a PR for the crash? I
suppose the alternatives are either to try not to tickle the crash in
our source, or fixing the 3.4.1 compiler?

> I also had to hack the test-release.sh script to fix a number of problems 
> that I encountered during the 3.7.1 release, but haven't gotten to 
> upstreaming them.  E.g. the way the source code is checked out with symlinks 
> all over the place does not work, and I need to add a custom patch to 
> clang-tools-extra to make the tests succeed, because there is a race 
> condition in the Makefile.

:-( What's not working with the symlinks? Please send patches. I'm
sorry for the trouble here.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

On Wed, Jan 20, 2016 at 7:54 AM, Ben Pope  wrote:
> On Wednesday, January 20, 2016 07:47 AM, Hans Wennborg wrote:
>>
>> Dear testers,
>>
>> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
>> r258223. (It took a little longer than I'd planned, sorry about that.)

> Some issues:
>
> LNT didn't finish: perhaps my checkout is incomplete, this bit seems to have
> changed with the switch to cmake.  Some unexpected failures on Ubuntu 14.04,
> but 15.10 was great.

How did you build LNT? I think previously it used to get configured
automatically, but not built. Recently someone added a cmake file to
it, which didn't work, so I excluded it from the test-release build in
r257791

>
> LNT:
> nt.py:499: fatal error: unable to import test module:
> '3.8.0/rc1/test-suite.src/LNTBased/speccpu2000/int/164.gzip/TestModule'
> Traceback (most recent call last):
>   File "/home/ben/development/llvm/lnt/lnt/tests/nt.py", line 495, in
> execute_test_modules
> exec module_file in locals, globals
>   File
> "3.8.0/rc1/test-suite.src/LNTBased/speccpu2000/int/164.gzip/TestModule",
> line 4, in 
> import spec
> ImportError: No module named spec
>
> Ubuntu 14.04 x86_64:
> Failing Tests (14):
> AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc
> MemorySanitizer :: Linux/forkpty.cc
> MemorySanitizer :: Linux/tcgetattr.cc
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent
> MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent_r
> 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.gethostent
> MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.gethostent_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

Weird. These all passed for me on 14.04.

>
> Uploaded:
> clang+llvm-3.8.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
> clang+llvm-3.8.0-rc1-x86_64-linux-gnu-ubuntu-15.10.tar.xz

Thanks!
___
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] We have branched

[Hans Wennborg via lldb-dev]

On Wed, Jan 20, 2016 at 7:32 AM, Renato Golin  wrote:
> Hans, Daniel,
>
> How are things going? It's been 5 days and no word. I'm running the
> tests now, just in case, but would be good to know that no one would
> be committing to the release candidate 1 tree in the mean time.

Did you send this before I sent the rc1 email, or what things are you
referring to? :-)




> On 15 January 2016 at 15:56, Daniel Sanders via llvm-dev
>  wrote:
>>> -Original Message-
>>> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf
>>> Of Hans Wennborg
>>> Sent: 15 January 2016 15:52
>>> To: Daniel Sanders
>>> Cc: llvm-dev; lldb-dev@lists.llvm.org; openmp-...@lists.llvm.org; cfe-
>>> d...@lists.llvm.org
>>> Subject: Re: [cfe-dev] [3.8 Release] We have branched
>>>
>>> Hi Daniel,
>>>
>>> Thanks for trying out the branch :-)
>>>
>>> On Fri, Jan 15, 2016 at 5:30 AM, Daniel Sanders
>>>  wrote:
>>> > Hi Hans,
>>> >
>>> > I tried the release branch last night and I'm having problems building 
>>> > it. The
>>> problem is that test-suite is now building as part of the Phase[123] builds
>>> (because this project contains CMakeLists.txt's now) but cmake 3.0.2 (from
>>> Debian Jessie) generates an invalid Makefile.
>>> > The error is:
>>> > CMakeFiles/test-suite.dir/build.make:112: *** target pattern 
>>> > contains
>>> no '%'.  Stop.
>>> > CMakeFiles/Makefile2:199: recipe for target 'CMakeFiles/test-
>>> suite.dir/all' failed
>>> > And the referenced line of the generated makefile is:
>>> > test-suite-stamps/test-suite-force-rebuild: /home/das-local/llvm-
>>> release-3.8/release/branches_release_38/llvm.src/$
>>> > it looks like cmake isn't fully expanding its generator expressions.
>>> >
>>> > Looking at my logs, it looks like the test-suite used to configure in 
>>> > 3.6.2 but
>>> didn't build as part of test-release.sh and then 3.7.0 stopped since we had
>>> switched to cmake and there was no CMakeLists.txt.
>>> > I've always run the test-suite as a separate step as described in
>>> http://llvm.org/docs/ReleaseProcess.html. Should we stop creating the
>>> projects/test-suite symlink to get back to the behaviour from 3.7.0 or 
>>> should
>>> we do something else?
>>>
>>> Yes, I made the script stop making the symlink in r257791 and merged
>>> it to the branch. Did that not work for you, or were you at an earlier
>>> revision?
>>>
>>> Thanks,
>>> Hans
>>
>> I'm at r257773 so it looks like I didn't pick up that change. I'll give it 
>> another try tonight.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

On Wed, Jan 20, 2016 at 12:18 PM, Dimitry Andric  wrote:
> As to the symlinks, the test-release.sh script originally checks out the 
> sources in parallel directories, e.g.:
>
> llvm.src
> cfe.src
> compiler-rt.src
>
> and so on.  Within llvm.src, symlinks are made to point to each of these.  
> For some reason, on FreeBSD, this causes .cpp files under 
> llvm.src/tools/clang/tools/extra to not be able to find their include files, 
> and my log files show the following kind of errors:
>
> /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.
>
> I remember trying lots of things to make this work, but failing.  Apparently 
> there is some issue with following a double symlink path, e.g. 
> llvm.src/tools/clang is a symlink to ../../cfe.src, while 
> llvm.src/tools/clang/tools/extra (which really is under ../../cfe.src/tools) 
> is a symlink to ../../clang-tools-extra.src.

Oh, I thought it was a CMake vs. autoconf thing, and we were just
symlinking clang-tools-extra wrong (see r257905). I guess I jumped to
wrong conclusions there :-/

> The way I fixed this during the 3.7 test phase, is by changing 
> test-release.sh so it exports directly into these locations:
>
> # Exporting llvm 3.7.0-rc3 sources to llvm.src
> # Exporting cfe 3.7.0-rc3 sources to llvm.src/tools/clang
> # Exporting clang-tools-extra 3.7.0-rc3 sources to 
> llvm.src/tools/clang/tools/extra
> # Exporting compiler-rt 3.7.0-rc3 sources to llvm.src/projects/compiler-rt
> # Exporting libcxx 3.7.0-rc3 sources to llvm.src/projects/libcxx
> # Exporting libcxxabi 3.7.0-rc3 sources to llvm.src/projects/libcxxabi
> # Exporting libunwind 3.7.0-rc3 sources to llvm.src/projects/libunwind
> # Exporting test-suite 3.7.0-rc3 sources to llvm.src/projects/test-suite
>
> This is probably not so handy if you want to create tarballs of the 
> individual components, though.

Actually, I use export.sh for creating the tarballs, so that's not a
problem. Maybe just exporting into the right directories is the way to
go.
___
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

[Hans Wennborg via lldb-dev]

On Wed, Jan 20, 2016 at 5:02 PM, Ben Pope via cfe-dev
 wrote:
> On Thursday, January 21, 2016 01:28 AM, Hans Wennborg via cfe-dev wrote:
>>
>> On Wed, Jan 20, 2016 at 7:54 AM, Ben Pope  wrote:
>>>
>>> On Wednesday, January 20, 2016 07:47 AM, Hans Wennborg wrote:


 Dear testers,

 Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
 r258223. (It took a little longer than I'd planned, sorry about that.)
>>
>>
>>> Some issues:
>>>
>>> LNT didn't finish: perhaps my checkout is incomplete, this bit seems to
>>> have
>>> changed with the switch to cmake.  Some unexpected failures on Ubuntu
>>> 14.04,
>>> but 15.10 was great.
>>
>>
>> How did you build LNT? I think previously it used to get configured
>> automatically, but not built. Recently someone added a cmake file to
>> it, which didn't work, so I excluded it from the test-release build in
>> r257791
>
>
> I only checked out the test-suite and ran LNT as I normally do. Do I need to
> "build" the test suite?

OK, that sounds good. I was worried it was getting pulled in and
failing through the CMake build in test-release.sh.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

On Thu, Jan 21, 2016 at 5:18 AM, Renato Golin  wrote:
> On 20 January 2016 at 09:31, Sylvestre Ledru  wrote:
>> What about creating a release management mailing list ?
>> The testers are usually the same (hello folks!) :)
>
> I second that! It'd also be much easier on mail filters... :)

Tanya, can you help us set up an llvm-release-testers mailing list?

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg  wrote:
> Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at
> r258223. (It took a little longer than I'd planned, sorry about that.)
>
> There are still a bunch of open merge requests and bug reports, but I
> wanted to get the tag in so we can see what the build and test status
> are on the various platforms.
>
> I verified that it currently builds and tests cleanly for me on x86_64
> Linux, Mac OS X* and Windows.
>
> Please build, test, and upload binaries to the sftp. Let me know if how it 
> goes.

Uploaded Win binaries to the sftp:
842c6b6165089cd0771020c0bdb542456690aab9  LLVM-3.8.0-rc1-win32.exe
5031bd338856b3cd06fce260c9cc1c2445536963  LLVM-3.8.0-rc1-win64.exe

 - Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

On Fri, Dec 11, 2015 at 3:14 PM, Hans Wennborg  wrote:
> 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 just realized no one actually signed up for testing and packaging on
Darwin. Any takers?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.8 Release] Release Candidate 1 source and binaries available

[Hans Wennborg via lldb-dev]

Hello everyone,

Source and binaries for LLVM-3.8.0-rc1 are now available at
http://llvm.org/pre-releases/3.8.0/

(Binaries for some platforms are still missing, but I figured it was
time to get this out there.)

Please try it, run tests, build your favourite projects, and *file
bugs* about anything that doesn't work and needs to be fixed for the
release. Please CC me on any findings.

Thanks,
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

[Hans Wennborg via lldb-dev]

On Sun, Jan 24, 2016 at 2:48 PM, Brian Cain  wrote:
>
> On Thu, Jan 21, 2016 at 9:52 PM, Brian Cain  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
>>>  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.
>>
>
> I discussed this more with Eric off-list and I think we've come to the
> conclusion that this was not a regression, it was my error.
>
> It's a bit tricky -- what should I expect for a new platform?  All failing
> tests are likely failing because they can't be/aren't yet supported?  It's
> tough to distinguish -- are they real bugs to be fixed, errors in the
> build/release process?

Ideally, all tests should pass on the platforms we build for. In your
case, it's not even very exotic, just x86_64 Linux. The LLVM and Clang
tests are pretty good in this regard, but various sanitizer and libc++
tests seem less stable. In practice, we've been releasing as long as
the failures don't look like regressions from previous releases.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Patch to fix REPL for ARMv7 & ARMv6 on linux

[Hans Wennborg via lldb-dev]

This patch looks reasonable to me, but I don't know enough about LLDB
to actually review it.

+Renato or Pavel maybe?

On Thu, Jan 14, 2016 at 11:32 AM, William Dillon via lldb-dev
 wrote:
> Hi again, everyone
>
> I’d like to ping on this patch now that the 3.8 branch is fairly new, and 
> merging it over is fairly straight-forward.
>
> Thanks in advance for your comments!
> - Will
>
>> There is a small change that enables correct calculation of arm sub 
>> architectures while using the REPL on arm-linux.  As you may of may or may 
>> not know, linux appends ‘l’ to arm architecture versions to denote little 
>> endian.  This sometimes interferes with the determination of the 
>> architecture in the triple.  I experimented with adding sub architecture 
>> entries for these within lldb, but I discovered a simpler (and less 
>> invasive) method.  Because LLVM already knows how to handle some of these 
>> cases (I have a patch submitted for review that enables v6l; v7l already 
>> works), I am relying on llvm to clean it up.  The gist of it is that the 
>> llvm constructor (when given a triple string) retains the provided string 
>> unless an accessor mutates it.  Meanwhile, the accessors for the components 
>> go through the aliasing and parsing logic.  This code detects whether the 
>> sub-architecture that armv6l or armv7l aliases to is detected, and re-sets 
>> the architecture in the triple.  This overwrites the architecture that comes 
>> from linux, thus sanitizing it.
>>
>> Some kind of solution is required for the REPL to work on arm-linux.  
>> Without it, the REPL crashes.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.8 Release] RC2 has been tagged

[Hans Wennborg via lldb-dev]

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

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

[Hans Wennborg via lldb-dev]

On Tue, Feb 2, 2016 at 1:15 PM, Hans Wennborg  wrote:
> Release Candidate 2 has just been tagged [1]. Please build, test, and
> upload to the sftp.

Windows binaries are up: (sha1 sums)
23e18a4af76bed48ca8975a1b90b53b960508964  LLVM-3.8.0-rc2-win32.exe
87174857cdf76ac99b610672a3f721e4df300dda  LLVM-3.8.0-rc2-win64.exe
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.8 Release] Release Candidate 2 source and binaries available

[Hans Wennborg via lldb-dev]

Hello everyone,

Source, binaries and documentation for LLVM-3.8.0-rc2 is now available
at http://llvm.org/pre-releases/3.8.0/#rc2

Please try them out, run tests, build your favourite projects, and
*file bugs* about anything that doesn't work and needs to be fixed for
the release. Please CC me on any findings.

Many thanks to all our release testers and packagers for putting the
binaries together!

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] Release Candidate 2 source and binaries available

[Hans Wennborg via lldb-dev]

On Mon, Feb 8, 2016 at 3:08 PM, Renato Golin  wrote:
> On 8 February 2016 at 22:56,   wrote:
>> Imho it's critical to get parallel programming working on ARMv8 ( even if 
>> it's crappy OMP) to start. Please enable it and I'll run the tests against 
>> our internal QA and we can informally handle testing / guarding against 
>> regressions.
>
> Ok, I'll do it with rc3.

Sounds good to me, but if it doesn't build, or there are other
problems, I won't treat them as blocking 3.8.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.8 Release] Release status

[Hans Wennborg via lldb-dev]

According to the schedule (e.g. on the right on llvm.org), we should
have tagged the release by now, but we haven't, so we're officially
behind schedule. I'm still optimistic that we can wrap this up pretty
soon, though.

This is what's blocking us:

- PR26509: Crash in InnerLoopVectorizer::vectorizeLoop()
  I'm waiting to hear what Cong comes up with, otherwise we can revert
r255691 on the branch

- Shrink-wrapping vs TLS: Davide and Quentin are working on it

- PR26600: Loop vectorization creates an unsafe out-of-bounds load
  There's a patch out: http://reviews.llvm.org/D17332
  But no comments yet.. Hal?

- PR26564: Performance regression in AA
  Patch in review, but it makes me a little uneasy since it's big and
requires pulling in some refactoring patches too :-/

- ARM: fix VFP asm constraints: http://reviews.llvm.org/D17349
  It's not a regression, but I'll take it if it lands real soon.

- PR26500: shrink-wrapping vs PPC
  Patch in review: http://reviews.llvm.org/D17294
  Looks like it's moving along.

- PR26081: Assertion failed: (BitWidth == RHS.BitWidth && ...
  I believe Matthias is working on it?
  Will revert r252839 to unblock otherwise.

- PR26485: regression lowering TLS access in C on Darwin
  Is no one looking? :-(

If you're on one of these bugs or code reviews, etc., please try to
prioritize them if you can.

Also, please let me know if my list is missing something.

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.8 Release] Release status

[Hans Wennborg via lldb-dev]

Many thanks to everyone who helped out after this email yesterday!

Here's an update on the remaining issues. As you can see, it's a much
shorter list :-) I'm hoping to tag rc3 very soon.

Thanks again,
Hans

On Thu, Feb 18, 2016 at 4:22 PM, Hans Wennborg  wrote:
> - Shrink-wrapping vs TLS: Davide and Quentin are working on it
Fix is in r261387, will merge once it's baked in the tree for a bit.

> - PR26564: Performance regression in AA
>   Patch in review, but it makes me a little uneasy since it's big and
> requires pulling in some refactoring patches too :-/
Keeping an eye on it, but it's not blocking.

> - PR26500: shrink-wrapping vs PPC
>   Patch in review: http://reviews.llvm.org/D17294
Looks like it's pretty much ready to land.

> - PR26485: regression lowering TLS access in C on Darwin
Fix is in r261384, will merge after it's been in-tree for a while.

- r261297 - Implement the likely resolution of core issue 253.
  New from yesterday. Might want to merge this. Post-commit review
  is still ongoing.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [3.8 Release] Release status

[Hans Wennborg via lldb-dev]

I had hoped to tag rc3 today (I feel like I've said this a lot
lately), but it's at least really, really close. I'm waiting for:

- r261297 - Implement the likely resolution of core issue 253.
  Still in post-commit review.

- D17507 - The controlling expression for _Generic is unevaluated
  New for today. Waiting for review.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.8 Release] RC3 has been tagged

[Hans Wennborg via lldb-dev]

Dear testers,

Release Candidate 3 has just been tagged [1]. Please build, test, and
upload to the sftp.

If there are no regressions from previous release candidates, this
will be the last release candidate before the final release.

Release notes can still go into the branch.

Thanks again for all your work!
Hans

 [1] 
http://lists.llvm.org/pipermail/llvm-branch-commits/2016-February/009866.html
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [3.8 Release] Release status

[Hans Wennborg via lldb-dev]

On Mon, Feb 22, 2016 at 11:47 PM, Ismail Donmez  wrote:
> On Tue, Feb 23, 2016 at 5:48 AM, Hans Wennborg via Openmp-dev
>  wrote:
>> I had hoped to tag rc3 today (I feel like I've said this a lot
>> lately), but it's at least really, really close. I'm waiting for:
>>
>> - r261297 - Implement the likely resolution of core issue 253.
>>   Still in post-commit review.
>
> I originally wanted this one but the fix involved even more discussion
> so I guess it would be safer to put it in 3.8.1 instead.

Right. Since this seems complicated, and not strictly fixing a
regression, I'm not going to wait for it.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

On Tue, Feb 23, 2016 at 1:51 PM, Hans Wennborg  wrote:
> Release Candidate 3 has just been tagged [1]. Please build, test, and
> upload to the sftp.

Windows (sha1):
76f8f91debd2e101b9adc4a6f2230fcd5e18bb5c  LLVM-3.8.0-rc3-win32.exe
b87654327d3ae537f8afec06ea0fa63121b9a86e  LLVM-3.8.0-rc3-win64.exe

 - Hans
___
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

[Hans Wennborg via lldb-dev]

On Tue, Feb 23, 2016 at 8:51 PM, Ben Pope  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.
>
>
> On Ubuntu 15.10 x86_64 I got:
>
> Failing Tests (2):
> MemorySanitizer :: Linux/forkpty.cc
> MemorySanitizer :: Linux/tcgetattr.cc
>
>   Expected Passes: 31860
>   Expected Failures  : 209
>   Unsupported Tests  : 648
>   Unexpected Failures: 2
>
> With RC2 there were no failures, but it looks like 15 tests have been added.

Hmm, those two tests are not new, but maybe something changed that
made them run now and not before. Perhaps related to r261162? In any
case, I'm not too worried about these failures, they probably just
didn't run before.

Thanks,
Hans
___
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

[Hans Wennborg via lldb-dev]

On Mon, Feb 29, 2016 at 2:20 AM, Daniel Sanders
 wrote:
> clang+llvm-3.8.0-rc3-x86_64-linux-gnu-debian8.tar.xz (sha1sum: 
> 2dedc6136d7cfbac8348652c543887964d92393c)
> Native: All ok
> Cross compiling to MIPS: All ok
>
> clang+llvm-3.8.0-rc3-mips-linux-gnu.tar.xz (sha1sum: 
> f286149dbb2ea7e194c5c3719b6cded476f6e65f)
> All ok (aside from non-regression failures in check-all).
> There were two kinds of check-all failure:
> * mips64 sanitizers. Not a regression since mip64 sanitizers didn't 
> ship in 3.7.1
> * atomic tests fail due to missing -latomic on link. Not a regression 
> since _no_ libc++ tests ran in 3.7.1 (this was obscured by the -s on 
> llvm-lit).
> Failing Tests (76):
> AddressSanitizer-mips64-linux :: 
> TestCases/Posix/coverage-direct-activation.cc
> AddressSanitizer-mips64-linux :: 
> TestCases/Posix/coverage-direct-large.cc
> AddressSanitizer-mips64-linux :: 
> TestCases/Posix/coverage-direct.cc
> AddressSanitizer-mips64-linux :: 
> TestCases/Posix/coverage-fork-direct.cc
> AddressSanitizer-mips64-linux :: TestCases/Posix/coverage.cc
> DataFlowSanitizer :: custom.cc
> DataFlowSanitizer :: propagate.c
> LeakSanitizer-AddressSanitizer :: TestCases/swapcontext.cc
> LeakSanitizer-AddressSanitizer :: TestCases/use_registers.cc
> LeakSanitizer-Standalone :: TestCases/swapcontext.cc
> LeakSanitizer-Standalone :: TestCases/use_registers.cc
> MemorySanitizer :: Linux/process_vm_readv.cc
> MemorySanitizer :: allocator_mapping.cc
> MemorySanitizer :: dlerror.cc
> MemorySanitizer :: dtls_test.c
> MemorySanitizer :: memcmp_test.cc
> MemorySanitizer :: msan_print_shadow3.cc
> MemorySanitizer :: param_tls_limit.cc
> MemorySanitizer :: unaligned_read_origin.cc
> MemorySanitizer-Unit :: 
> Msan-mips64-Test/MemorySanitizer.SmallPreAllocatedStackThread
> MemorySanitizer-Unit :: 
> Msan-mips64-Test/MemorySanitizer.UnalignedLoad
> MemorySanitizer-Unit :: 
> Msan-mips64-Test/MemorySanitizer.UnalignedStore16
> MemorySanitizer-Unit :: 
> Msan-mips64-Test/MemorySanitizer.UnalignedStore16_precise
> MemorySanitizer-Unit :: 
> Msan-mips64-Test/MemorySanitizer.UnalignedStore16_precise2
> MemorySanitizer-Unit :: 
> Msan-mips64-Test/MemorySanitizer.UnalignedStore32
> MemorySanitizer-Unit :: 
> Msan-mips64-Test/MemorySanitizer.gethostbyname_r_erange
> MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.ptrtoint
> MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.shmat
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.SmallPreAllocatedStackThread
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.UnalignedLoad
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16_precise
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore16_precise2
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.UnalignedStore32
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.gethostbyname_r_erange
> MemorySanitizer-Unit :: 
> Msan-mips64-with-call-Test/MemorySanitizer.ptrtoint
> SanitizerCommon-Unit :: 
> Sanitizer-mips64-Test/SanitizerCommon.FileOps
> SanitizerCommon-Unit :: 
> Sanitizer-mips64-Test/SanitizerIoctl.KVM_GET_LAPIC
> SanitizerCommon-Unit :: 
> Sanitizer-mips64-Test/SanitizerIoctl.KVM_GET_MP_STATE
> SanitizerCommon-asan :: Linux/getpwnam_r_invalid_user.cc
> SanitizerCommon-lsan :: Linux/getpwnam_r_invalid_user.cc
> ThreadSanitizer-mips64 :: atexit2.cc
> ThreadSanitizer-mips64 :: deadlock_detector_stress_test.cc
> ThreadSanitizer-mips64 :: java_alloc.cc
> ThreadSanitizer-mips64 :: java_race_pc.cc
> ThreadSanitizer-mips64 :: longjmp.cc
> ThreadSanitizer-mips64 :: longjmp2.cc
> ThreadSanitizer-mips64 :: longjmp3.cc
> ThreadSanitizer-mips64 :: longjmp4.cc
> ThreadSanitizer-mips64 :: map32bit.cc
> ThreadSanitizer-mips64 :: race_on_mutex.c
> ThreadSanitizer-mips64 :: signal_longjmp.cc
> libc++ :: std/atomics/atomics.types.generic/integral.pass.cpp
> libc++ :: 
> std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_strong.pass.cpp
> libc++ :: 
> std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_strong_explicit.p

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

[Hans Wennborg via lldb-dev]

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.

Many thanks for all your work!
Hans

 [1]. http://lists.llvm.org/pipermail/llvm-branch-commits/2016-March/009883.html
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

On Wed, Mar 2, 2016 at 4:33 PM, Hans Wennborg  wrote:
> Please build the final binaries and upload to the sftp.

Mac and Windows uploaded (sha1sum):
8d1f41aee5f3b29f14db90141430faee5e0d7723
clang+llvm-3.8.0-x86_64-apple-darwin.tar.xz
f30de7ee8006dc779064202bcc345c418c1ac249  LLVM-3.8.0-win32.exe
325cadbcbb45649750434906b229e5f1e6438231  LLVM-3.8.0-win64.exe

 - Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM 3.8 Release

[Hans Wennborg via lldb-dev]

It is my pleasure to announce that LLVM 3.8.0 is now available!

Get it here: http://www.llvm.org/releases/download.html#3.8.0

This release contains the work of the LLVM community over the past six
months: deprecated autoconf build, shrink-wrapping on by default,
overhauled MSVC-compatible exception handling, updated Kaleidoscope
tutorial, emutls, OpenMP supported by default, as well as improved
optimizations, many bug fixes, and more.

Release notes for more details:
http://llvm.org/releases/3.8.0/docs/ReleaseNotes.html
http://llvm.org/releases/3.8.0/tools/clang/docs/ReleaseNotes.html

Huge thanks to everyone who helped with testing, bug fixing,
packaging, and getting the release into a good state!

Special thanks to the volunteer release builders and testers, without
whom there would be no releases: Dimitry Andric, Brian Cain, Ismail
Donmez, Renato Golin, Sylvestre Ledru, Elias Pipping, Ben Pope, Daniel
Sanders, and Nikola Smiljanic!

If you have any questions or comments about the release, please
contact the community on the mailing lists. Onward to 3.9!

 - Hans

(LLVM 3.7.1 Release Announcement:
http://lists.llvm.org/pipermail/llvm-announce/2016-January/66.html)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Bug fixes for release_38 branch

[Hans Wennborg via lldb-dev]

+Tom who owns the 3.8.1 release

On Tue, May 3, 2016 at 10:04 AM, Francis Ricci via lldb-dev
 wrote:
> I didn't have any luck with r266423, these dwarf issues can get pretty
> tricky.
>
> Ok, that makes sense. We've been using these commits on top of our
> release_38 branch for several weeks now, and I'm happy with their stability.
> I'll continue to be on the lookout for bugs and bug-fixes.
>
> Hans, can we get these commits cherry-picked onto release_38?
>
> Thanks!
> Francis
>
>
> On Fri, Apr 29, 2016 at 11:40 AM Pavel Labath  wrote:
>>
>> As Tamas said, little effort has gone into the to stabilization of the
>> 3.8 branch. Right now, you're the only one looking into it, so I think
>> we'll just defer to your judgement. It is a bit of a duplication of
>> effort but, I think it is very worthwhile for lldb project as a whole.
>>
>> For the multithreaded dwarf parsing thing, if you are feeling
>> adventurous, you might want to try if r266423 fixes your problems, but
>> I think the idea of reverting that part is very reasonable as well.
>>
>> pl
>>
>>
>> On 29 April 2016 at 19:03, Francis Ricci via lldb-dev
>>  wrote:
>> > I needed to have a (recent) branch of lldb which was stable for
>> > debugging
>> > across platforms (native darwin, native linux, android, etc). I
>> > originally
>> > tried using the google/stable branch (which I assume is what ships with
>> > Android Studio), but that had some crashes with darwin debugging. I had
>> > assumed that the branch shipped with xcode was a private release branch.
>> > Since using either google/stable or release_38 would require
>> > stabilization,
>> > I decided that going ahead and stabilizing release_38 would probably be
>> > worthwhile. I assume that this would be beneficial for non-developers
>> > who
>> > use lldb outside of xcode/android studio as well, given that they may
>> > install the linux package for the most recent stable release branch.
>> >
>> > On Fri, Apr 29, 2016 at 5:28 AM Tamas Berghammer
>> > 
>> > wrote:
>> >>
>> >> Is there any reason you want to use the release_38 branch specifically?
>> >> As
>> >> far as I know nobody tested it or using it in the LLDB community so it
>> >> is
>> >> approximately as good as any random commit on master. If you are
>> >> looking for
>> >> a reasonably stable LLDB then I think you are better off with asking
>> >> for the
>> >> version number shipped with xcode or with Android Studio as those
>> >> versions
>> >> are a bit more tested and it is used by some users as well.
>> >>
>> >> On Thu, Apr 28, 2016 at 8:57 PM Francis Ricci via lldb-dev
>> >>  wrote:
>> >>>
>> >>> Over the last month or two, I've been working to stabilize the
>> >>> release_38
>> >>> branch of lldb, and there are commits which fix bugs on this branch
>> >>> that I'd
>> >>> like to cherry-pick down. They're listed at the bottom of this
>> >>> message.
>> >>>
>> >>> One thing to note - r251106 is a commit I'd like to revert, instead of
>> >>> a
>> >>> cherry-pick. When we use this commit (multithreaded dwarf parsing) on
>> >>> the
>> >>> 3.8 branch, I run into a lot of dwarf assertion failures, even after
>> >>> cherry-picking all the dwarf fixes I could find from master. I don't
>> >>> see
>> >>> these assertion failures on master, so it's definitely an issue that's
>> >>> been
>> >>> fixed since the branch cut, but I think the best solution for the
>> >>> release_38
>> >>> branch is to disable it for now.
>> >>>
>> >>> r264810 will have a small merge conflict due to an indentation change
>> >>> in
>> >>> lldbpexpect.py
>> >>> r263735 will have a small merge conflict due to a whitespace change on
>> >>> master. Everything else should apply cleanly.
>> >>>
>> >>> Commits:
>> >>> r267741 Use absolute module path when possible if sent in svr4 packets
>> >>> r264810 Fixed the failing test TestCommandScriptImmediateOutput on
>> >>> MacOSX
>> >>> r267468 Maintain register numbering across xml include features
>> >>> r267467 Properly unload modules from target image list when using svr4
>> >>> packets
>> >>> r267466 Use Process Plugin register indices when communicating with
>> >>> remote
>> >>> r267463 Store absolute path for lldb executable in dotest.py
>> >>> r267462 Create _lldb python symlink correctly when LLVM_LIBDIR_SUFFIX
>> >>> is
>> >>> used
>> >>> r265422 Fix dotest.py '-p' option for multi-process mode
>> >>> r265420 Print environment when dumping arch triple
>> >>> r265419 Make sure to update Target arch if environment changed
>> >>> r265418 Allow gdbremote process to read modules from memory
>> >>> r264476 Fix FILE * leak in Python API
>> >>> r264351 Make File option flags consistent for Python API
>> >>> r263824 Fixed a bug where DW_AT_start_scope would fall through to
>> >>> DW_AT_artificial in SymbolFileDWARF::ParseVariableDIE(). This was
>> >>> caught by
>> >>> the clang warning that catches unannotated case fall throughs.
>> >>> r263735 Fix deadlock due to thread list locking in 'bt all' with obj-c
>> >>> r261858 Handle 

[lldb-dev] [3.9 Release] Release plan and call for testers

[Hans Wennborg via lldb-dev]

Hello everyone,

It's time to start planning for the 3.9 release.

Please let me know if you'd like to help providing binaries and
testing for your favourite platform.

I propose the following schedule:

- 18 July: Create the release branch; build and test RC1 soon thereafter.

- 1 August: Tag, build and test RC2. Any unfinished features need to
be turned off by now. As we get closer to the release, the bar for
merging patches rises.

- 22 August: Tag 3.9.0-final. The release ships when binaries are ready.


Also, I have three more questions for the community:

1) Right after the branch, the version number of the trunk will be
incremented. I assume this means bumping the major version number,
taking us to 4.0? IIUC, that's what happened after 1.9 and 2.9.

2) Following up on the May thread about the release process [1], I'd
like to make the schedule we've followed for the last few years more
official by posting somewhere on the web page that we're committed to
shipping two major releases per year: one in early March (branching
mid-January), and one early September (branching mid-July), usually
with one (or sometimes two) "dot" releases in between.

3) Another follow-up from that thread: it's usually the same people
who test the releases for their platform. Rather than asking everyone
each time, I'd like to make a list of who's responsible for each
platform and put that on the web page. Testers can still sign-up or
resign as they like, of course. Would you testers be OK with this?

Let me know what you think.

Cheers,
Hans


 [1]. http://lists.llvm.org/pipermail/llvm-dev/2016-May/099541.html
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Hans Wennborg via lldb-dev]

On Mon, Jun 13, 2016 at 9:24 AM, Robinson, Paul via cfe-dev
 wrote:
>
>
>> -Original Message-
>> From: llvm-dev [mailto:llvm-dev-boun...@lists.llvm.org] On Behalf Of
>> Rafael Espíndola via llvm-dev
>> Sent: Monday, June 13, 2016 7:47 AM
>> To: Tom Stellard
>> Cc: llvm-dev; Release-testers; openmp-dev (openmp-...@lists.llvm.org);
>> LLDB Dev; cfe-dev
>> Subject: Re: [llvm-dev] [3.9 Release] Release plan and call for testers
>>
>> On 13 June 2016 at 10:11, Tom Stellard  wrote:
>> > On Mon, Jun 13, 2016 at 09:14:43AM -0400, Rafael Espíndola wrote:
>> >> > The 4.1 release gives us the opportunity to drop support for 3.x
>> >> > bitcode formats, so  I don't think we should move to 4.x until we
>> have
>> >> > older bitcode features that we really want to drop.  There should
>> >> > probably be a separate discussion thread about this.
>> >>
>> >> It give the opportunity, not the obligation. Given that I think it is
>> >> an independent issue and would suggest we just keep the revisions
>> >> simple and switch trunk to 4.0.
>> >>
>> >
>> > Hi Rafael,
>> >
>> > The main issue I see with automatically moving to 4.0, is that if a year
>> > from now we decide we want to drop a bitcode feature, we can't really do
>> > it unless we bump the major version again to 5.0.  If we continue on
>> > with 3.x, then we still have the flexibility to drop bitcode features
>> > when we decide it's necessary.
>>
>> OK, I guess that is where your reading of the version differ.
>>
>> I read that we promise that 4.0 will read all of 3.X, but make no
>> further promises. That means that in 4.1 we *can* drop support for all
>> 3.x, keep support for everything or something in the middle. But that
>> is also true for 4.2. So for example it would be valid that
>>
>> * 4.0 reads all of 3.x
>> * 4.1 reads >= 3.1
>> * 4.2 reads >= 3.3
>
> I don't know that the actual policy has ever been formally documented,
> although it has been discussed from time to time, so it's not too
> surprising that people have different ideas of what the policy is.
>
> Maybe documenting the release-numbering-semantics policy alongside
> the release-timing policy would be a good idea?

If someone could just let me know what the policy actually is.. ;-)
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

Breaking this out into a separate thread since it's kind of a separate
issue, and to make sure people see it.

If you have opinions on this, please chime in. I'd like to collect as
many arguments here as possible to make a good decision. The main
contestants are 4.0 and 3.10, and I've seen folks being equally
surprised by both.

Brain-dump so far:

- After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0
comes after 3.9.

- There are special bitcode stability rules [1] concerning major
version bumps. 2.0 and 3.0 had major IR changes, but since there
aren't any this time, we should go to 3.10.

- The bitcode stability rules allow for breakage with major versions,
but it doesn't require it, so 4.0 is fine.

- But maybe we want to save 4.0 for when we do have a significant IR change?

- We've never had an x.10 version before; maybe that would be
confusing? Perhaps it's simply time to move on (like Linux 2.6.39 ->
3.0 and 3.19 -> 4.0).

- Since we do time-based rather than feature-based releases, the major
version number shouldn't mean anything special anyway (e.g. big IR
changes or not), so 4.0?

- Everyone knows that after 9 comes 10, so 3.10 it is. The version is
a tuple after all.

- Let's go for 4.0 now, and 5.0 after that. Then the "dot"-releases in
between would correspond to minor version bumps, which would make
sense (and catch up with GCC!).

- It's just a number, no big deal; flip a coin or something.

What do you think?

 - Hans


 [1]. http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [3.9 Release] Release plan and call for testers

[Hans Wennborg via lldb-dev]

I've split the version discussion off into a new thread ("What version
comes after 3.9?") and CC'd everyone discussing it here so far.

On Mon, Jun 13, 2016 at 11:23 AM, Mehdi Amini via llvm-dev
 wrote:
>
>> On Jun 13, 2016, at 6:14 AM, Rafael Espíndola via llvm-dev 
>>  wrote:
>>
>>> The 4.1 release gives us the opportunity to drop support for 3.x
>>> bitcode formats, so  I don't think we should move to 4.x until we have
>>> older bitcode features that we really want to drop.  There should
>>> probably be a separate discussion thread about this.
>>
>> It give the opportunity, not the obligation.
>
> I don't see this way: it means that we stop supporting compatibility, even if 
> we don't aggressively remove the auto-upgradecode. It looks like an important 
> decision and we should not take it lightly.
>
> --
> Mehdi
>
>
>> Given that I think it is
>> an independent issue and would suggest we just keep the revisions
>> simple and switch trunk to 4.0.
>>
>> Cheers,
>> Rafael
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg  wrote:
> Breaking this out into a separate thread since it's kind of a separate
> issue, and to make sure people see it.
>
> If you have opinions on this, please chime in. I'd like to collect as
> many arguments here as possible to make a good decision. The main
> contestants are 4.0 and 3.10, and I've seen folks being equally
> surprised by both.

Thanks everyone for chiming in.

Please correct me if I misrepresent your opinion here, but I need to
try and summarize this thread for my own sanity:

The thread started out with lots of support for 3.10, the reasoning
being roughly that we shouldn't bump the major version number unless
we want to signify major change (Mehdi, Hal, Blaikie, Saleem,
Chandler, Anton, Eric, Aaron, Sean, Vikram).

Richard suggested that since we do time-based rather than
feature-based releases, the distinction between a release with or
without major changes is arbitrary, and we should move to a scheme
where we update the major version number on each release (4.0, 5.0,
etc.) with minor releases in between (4.1, 5.1, ..).

Chris advocated for "keep adding 0.1 to each major release" (in the
decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone else
suggest this. "I do not think it is reasonable at all to go to '3.10'
after '3.9', because we will never get to '4.0'."

Chris then expressed support for alternatively just incrementing the
major version each time, as Richard suggested, but starting at 40.

Rafael expressed support for the above, but starting at 4.0: "It is
simply not worth the time to try to figure out what is 'major' in a
project with so many different uses."

Chandler said he didn't like Chris's "keep adding 0.1 to each major
release" scheme: "we shouldn't just go from 3.9 to 4.0 because of some
decimal correspondence", and said he was open to either going to 3.10
with the current major/minor split, or if we don't want that, use
Richard's suggestion.

Michael pointed out that if we do change the numbering scheme,
changing the binary compatibility guarantee to something time-based
isn't equivalent to what we currently have.



So, it seems we're at an impasse with several folks in favour of 3.10,
Chris speaking out strongly against it, and Richard's option which has
some traction and which no one's disagreed with so far, but which
would be a bigger change.

I'll have a think about this over the weekend.

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] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

On Fri, Jun 24, 2016 at 5:55 PM, Saleem Abdulrasool
 wrote:
> On Fri, Jun 24, 2016 at 5:43 PM, Dmitri Gribenko via cfe-dev
>  wrote:
>>
>> On Fri, Jun 24, 2016 at 4:41 PM, Hans Wennborg via llvm-dev
>>  wrote:
>> > Richard suggested that since we do time-based rather than
>> > feature-based releases, the distinction between a release with or
>> > without major changes is arbitrary, and we should move to a scheme
>> > where we update the major version number on each release (4.0, 5.0,
>> > etc.) with minor releases in between (4.1, 5.1, ..).
>>
>> If we are truly committed to doing time-based releases, we can switch
>> to time-based version numbers, Year.Month, for example, if we were to
>> release in June it would be 16.06.  We can use an extra digit for
>> minor releases.
>
>
> This would mirror other projects doing the same, so there is precedent.
> Although radically different from the current model, I think it has some
> merit.  When people report bugs with 3.1, its actually hard to estimate how
> it is (roughly estimating it via ~6mo release cycle does really work).  This
> would certainly make it easier.
>
> Its a good alternative though it does mean that we no longer have the
> ability to indicate a major shift.  However as Chris already pointed out,
> LLVM is much more stable these days and perhaps worrying about major shifts
> which are unseen is looking for a problem to solve rather than solving a
> problem at hand.
>
> +1 on this suggestion.

I'm not a fan of this idea. While I can see the reasoning behind it, I
think we would end up with pretty confusing-looking version numbers. I
suppose it's too radically a departure from the usual schemes for my
taste.

Thanks,
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] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth via cfe-dev
 wrote:
> On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev
>  wrote:
>>
>> I also believe this is the simplest versioning scheme*. It eliminates all
>> future debates on this topic (e.g, when to bump major version etc) and
>> solves the problem once and for all --  which is another plus :)
>
>
> Except that we'll have to keep dealing with people who are confused why we
> have two version numbers but they don't mean anything. That's why I think if
> we don't want major/minor going forward, we should remove the '.' regardless
> of what number we pick.

We can't remove the '.' completely though, as we need it for Tom's
stable releases.

That's what concerns me about going to the scheme Richard and Rafael
suggested, of bumping the major version each time: we'd release 4.0,
and would Tom's dot-release then be 4.1? That would be confusing to
those who are used to our current scheme. Chris suggested going
straight to 40 to avoid this, but that also seems a bit extreme.

Thanks,
Hans


>> On Sun, Jun 26, 2016 at 7:21 AM, Reid Kleckner via cfe-dev
>>  wrote:
>>>
>>> I also support Chris's position of 4.0, 4.1 etc. I don't think
>>> "majorness" is that important, and we can sort out the bit code
>>> compatibility story some other way.
>>>
>>> Sent from phone
>>>
>>> On Jun 24, 2016 4:42 PM, "Hans Wennborg via llvm-dev"
>>>  wrote:

 On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg 
 wrote:
 > Breaking this out into a separate thread since it's kind of a separate
 > issue, and to make sure people see it.
 >
 > If you have opinions on this, please chime in. I'd like to collect as
 > many arguments here as possible to make a good decision. The main
 > contestants are 4.0 and 3.10, and I've seen folks being equally
 > surprised by both.

 Thanks everyone for chiming in.

 Please correct me if I misrepresent your opinion here, but I need to
 try and summarize this thread for my own sanity:

 The thread started out with lots of support for 3.10, the reasoning
 being roughly that we shouldn't bump the major version number unless
 we want to signify major change (Mehdi, Hal, Blaikie, Saleem,
 Chandler, Anton, Eric, Aaron, Sean, Vikram).

 Richard suggested that since we do time-based rather than
 feature-based releases, the distinction between a release with or
 without major changes is arbitrary, and we should move to a scheme
 where we update the major version number on each release (4.0, 5.0,
 etc.) with minor releases in between (4.1, 5.1, ..).

 Chris advocated for "keep adding 0.1 to each major release" (in the
 decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone else
 suggest this. "I do not think it is reasonable at all to go to '3.10'
 after '3.9', because we will never get to '4.0'."

 Chris then expressed support for alternatively just incrementing the
 major version each time, as Richard suggested, but starting at 40.

 Rafael expressed support for the above, but starting at 4.0: "It is
 simply not worth the time to try to figure out what is 'major' in a
 project with so many different uses."

 Chandler said he didn't like Chris's "keep adding 0.1 to each major
 release" scheme: "we shouldn't just go from 3.9 to 4.0 because of some
 decimal correspondence", and said he was open to either going to 3.10
 with the current major/minor split, or if we don't want that, use
 Richard's suggestion.

 Michael pointed out that if we do change the numbering scheme,
 changing the binary compatibility guarantee to something time-based
 isn't equivalent to what we currently have.



 So, it seems we're at an impasse with several folks in favour of 3.10,
 Chris speaking out strongly against it, and Richard's option which has
 some traction and which no one's disagreed with so far, but which
 would be a bigger change.

 I'll have a think about this over the weekend.

 Cheers,
 Hans
 ___
 LLVM Developers mailing list
 llvm-...@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>> ___
>>> cfe-dev mailing list
>>> cfe-...@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>>
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> ___
> 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] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner  wrote:
> On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev 
>  wrote:
>> That's what concerns me about going to the scheme Richard and Rafael
>> suggested, of bumping the major version each time: we'd release 4.0,
>> and would Tom's dot-release then be 4.1? That would be confusing to
>> those who are used to our current scheme. Chris suggested going
>> straight to 40 to avoid this, but that also seems a bit extreme.
>
> Extreme how?  What do you mean by “extreme"?

Sorry, that might have been a poor choice of wording.

I just meant that change seems to have a much greater magnitude than
the other proposals. I realize that's sort of the point, to make the
change clear to users, but instinctively it feels wrong -- like
cheating by skipping 36 versions :-)

Thanks,
Hans
___
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] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

On Mon, Jun 27, 2016 at 3:40 PM, Chandler Carruth  wrote:
> On Mon, Jun 27, 2016 at 3:38 PM Hans Wennborg via lldb-dev
>  wrote:
>>
>> On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner  wrote:
>> > On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev
>> >  wrote:
>> >> That's what concerns me about going to the scheme Richard and Rafael
>> >> suggested, of bumping the major version each time: we'd release 4.0,
>> >> and would Tom's dot-release then be 4.1? That would be confusing to
>> >> those who are used to our current scheme. Chris suggested going
>> >> straight to 40 to avoid this, but that also seems a bit extreme.
>> >
>> > Extreme how?  What do you mean by “extreme"?
>>
>> Sorry, that might have been a poor choice of wording.
>>
>> I just meant that change seems to have a much greater magnitude than
>> the other proposals. I realize that's sort of the point, to make the
>> change clear to users, but instinctively it feels wrong -- like
>> cheating by skipping 36 versions :-)
>
>
> Eh, if we're switching to a completely unrelated versioning scheme, it
> doesn't seem completely unreasonable.
>
> We could also count how many time-based releases we have had and use that...
>
> :: shrug ::
>
> I think counting from 4 or counting from 40 are all fine ways to number
> releases.


This is what I arrived at after my weekend of thinking about version numbers:

While there's been many good arguments for doing something different
and revising our versioning scheme, I really just want to bump the
number with the least amount of work possible.

When we branch for 3.9, my plan is to bump trunk to 3.10, and then
focus my attention on getting 3.9 into a good state and shipping it.

After the branch, if someone wants to promote trunk to 4.0 because of
a feature, or because the 3-series is "done", go ahead. If someone
wants to spearhead getting us onto a scheme where we increment major
for each release, that's fine too, but I'm not going to drive it.

Thanks everyone for participating in the discussion. Hopefully this
result is not too disappointing.

Cheers,
Hans
___
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] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

On Mon, Jun 27, 2016 at 7:57 PM, Chris Lattner  wrote:
> On Jun 27, 2016, at 4:57 PM, Hans Wennborg  wrote:
>>> Eh, if we're switching to a completely unrelated versioning scheme, it
>>> doesn't seem completely unreasonable.
>>>
>>> We could also count how many time-based releases we have had and use that...
>>>
>>> :: shrug ::
>>>
>>> I think counting from 4 or counting from 40 are all fine ways to number
>>> releases.
>>
>>
>> This is what I arrived at after my weekend of thinking about version numbers:
>>
>> While there's been many good arguments for doing something different
>> and revising our versioning scheme, I really just want to bump the
>> number with the least amount of work possible.
>>
>> When we branch for 3.9, my plan is to bump trunk to 3.10, and then
>> focus my attention on getting 3.9 into a good state and shipping it.
>>
>> After the branch, if someone wants to promote trunk to 4.0 because of
>> a feature, or because the 3-series is "done", go ahead. If someone
>> wants to spearhead getting us onto a scheme where we increment major
>> for each release, that's fine too, but I'm not going to drive it.
>>
>> Thanks everyone for participating in the discussion. Hopefully this
>> result is not too disappointing.
>
> I continue to think that 3.10 is the least defensible option out there.  We 
> have a time based release process with no mechanism or attempt to align 
> behind “big” releases that could bring is to a 4.x number.  You might as well 
> call the release “10” at this point, since the "3.” will become archaic 
> legacy that we can’t shed.
>
> Trust me, I’ve seen this happen several times in the past in multiple 
> different products (both open source and proprietary), and have had success 
> leading one to a more predictable release number pattern like I’m advocating 
> for.  This is a problem that we are simply walking into by naming it 3.10, 
> there is no reason to do that.
>
> I still don’t understand what “confusion” could be caused by going from 3.9 
> to 4.0.  Could someone please elaborate on what the problem is that needs 
> solving?  If it is that people don’t understand what is major about the 
> release, I would say “who cares”?

I think the main issue (besides users asking what's the big change in
4.0, which I agree is not a big problem) is that the bitcode
compatibility policy is tied to the major version number.

But if you really insist on 4.0 rather than 3.10, I will of course honour that.

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] [Openmp-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

On Tue, Jun 28, 2016 at 1:17 PM, Richard Smith via lldb-dev
 wrote:
>> If 4 seems too confusing, and 40 seems too extreme, how about 10.
>> Seriously. It seems exactly as good as any other integer to start counting
>> rationally, and won't confuse people by looking like a 4.0 release.
>
>
> I think going to 10 or 40 is likely to be confusing, because there'll be two
> different ways to refer to the same version (people will say 3.10 when
> referring to version 10, or 38 when referring to version 3.8, respectively).
> This happened to Java in the version 1.6 / version 6 numbering transition.
>
> In order to preserve numbering continuity and minimize confusion, if we go
> from three-component versions (major.minor.patch) to two-component versions
> (major.patch), I would suggest we go from x.y.z to x+1.0. (This is also
> consistent with how GCC handled the transition.)

I haven't followed how this worked out for GCC, but I worry that if we
go from 3.9.0 to 4.0 with the intention of doing 5.0 next, users will
get confused when we ship 4.1 as a "dot" release instead of a major
release like we've used to.

There's also the question of how to practically go from a 3-tuple to a
2-tuple. Should we drop it from the version string and dir names in
Clang? Do we drop __clang_patchlevel__ or just leave it at zero? I see
GCC 5.4 is actually versioned as 5.4.0 so maybe that'd be the way to
do it?

Cheers,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [Openmp-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

On Tue, Jun 28, 2016 at 2:37 PM, Chris Lattner via llvm-dev
 wrote:
> On Jun 28, 2016, at 12:55 PM, Chandler Carruth via Openmp-dev
>  wrote:
>>
>> I think I agree with Chris with 3.10 being the worst possible outcome.
>
>
> I'd be interested to understand why you or Chris thing 3.10 is the worst
> possible outcome.
>
> Chris has said it is because he thinks we'll never change the "3”,
>
>
> Yes, that is one reason.
>
> but I don't understand why 3.10 is worse than 3.9 was in that respect.
>
>
> Because it breaks from the established pattern we have, and means that we
> never get to 4.
>
> I happen to agree that we'll never change the "3", but I don't think this
> makes 3.10 a particularly bad choice.
>
>
> If you agree that we’ll never change the 3, then you are staying that you
> believe it is ok for the version number to be meaningless.  In that case, I
> can’t see why you’d object to a policy change.
>
> I believe that the version number is important.  Which is why I care so much
> about it :-)
>
> I think/hope we can agree that “Bitcode compatibility” is an obsolete notion
> to encode into the version number - from a historical perspective, we only
> used that as rationale because it happened to align well for the 1.9 to 2.0
> conversion and then used it as an excuse to shed some legacy in the 3.0
> timeframe.
>
> Given that, and given that we have a time based release, we should either
> leave the versioning alone (3.9/4.0/4.1) or switch to a semantic versioning
> model 3.9/4.0/5.0/6.0 or 3.9/40/41/42).

Since there seems to be some kind of rough consensus forming around
the idea of moving towards a model with x.y version numbers where we
increment x every six months and y for the "dot" releases in between,
let's take it to a code review:

http://reviews.llvm.org/D21821

What angles am I missing? I'm sure this can break the world in
interesting ways. (It looks like Clang's cmake config is already set
up for this though, by checking CLANG_HAS_VERSION_PATCHLEVEL).

 - 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] [llvm-dev] [Openmp-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Hans Wennborg via lldb-dev]

On Tue, Jun 28, 2016 at 5:22 PM, Duncan P. N. Exon Smith
 wrote:
>
>> On 2016-Jun-28, at 16:22, Hans Wennborg via cfe-dev  
>> wrote:
>>
>> On Tue, Jun 28, 2016 at 2:37 PM, Chris Lattner via llvm-dev
>>  wrote:
>>> On Jun 28, 2016, at 12:55 PM, Chandler Carruth via Openmp-dev
>>>  wrote:

 I think I agree with Chris with 3.10 being the worst possible outcome.
>>>
>>>
>>> I'd be interested to understand why you or Chris thing 3.10 is the worst
>>> possible outcome.
>>>
>>> Chris has said it is because he thinks we'll never change the "3”,
>>>
>>>
>>> Yes, that is one reason.
>>>
>>> but I don't understand why 3.10 is worse than 3.9 was in that respect.
>>>
>>>
>>> Because it breaks from the established pattern we have, and means that we
>>> never get to 4.
>>>
>>> I happen to agree that we'll never change the "3", but I don't think this
>>> makes 3.10 a particularly bad choice.
>>>
>>>
>>> If you agree that we’ll never change the 3, then you are staying that you
>>> believe it is ok for the version number to be meaningless.  In that case, I
>>> can’t see why you’d object to a policy change.
>>>
>>> I believe that the version number is important.  Which is why I care so much
>>> about it :-)
>>>
>>> I think/hope we can agree that “Bitcode compatibility” is an obsolete notion
>>> to encode into the version number - from a historical perspective, we only
>>> used that as rationale because it happened to align well for the 1.9 to 2.0
>>> conversion and then used it as an excuse to shed some legacy in the 3.0
>>> timeframe.
>>>
>>> Given that, and given that we have a time based release, we should either
>>> leave the versioning alone (3.9/4.0/4.1) or switch to a semantic versioning
>>> model 3.9/4.0/5.0/6.0 or 3.9/40/41/42).
>>
>> Since there seems to be some kind of rough consensus forming around
>> the idea of moving towards a model with x.y version numbers where we
>> increment x every six months and y for the "dot" releases in between,
>> let's take it to a code review:
>>
>> http://reviews.llvm.org/D21821
>>
>> What angles am I missing? I'm sure this can break the world in
>> interesting ways. (It looks like Clang's cmake config is already set
>> up for this though, by checking CLANG_HAS_VERSION_PATCHLEVEL).
>
> For one thing, I can't find the patch on the mailing list ;).  I'm guessing
> you missed adding llvm-commits as a subscriber?

Good point :-) Added it now.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [3.9 Release] Release plan and call for testers

[Hans Wennborg via lldb-dev]

On Fri, Jun 10, 2016 at 1:38 PM, Hans Wennborg  wrote:
> 2) Following up on the May thread about the release process [1], I'd
> like to make the schedule we've followed for the last few years more
> official by posting somewhere on the web page that we're committed to
> shipping two major releases per year: one in early March (branching
> mid-January), and one early September (branching mid-July), usually
> with one (or sometimes two) "dot" releases in between.
>
> 3) Another follow-up from that thread: it's usually the same people
> who test the releases for their platform. Rather than asking everyone
> each time, I'd like to make a list of who's responsible for each
> platform and put that on the web page. Testers can still sign-up or
> resign as they like, of course. Would you testers be OK with this?

I've sent out a patch to update the docs for this:
http://reviews.llvm.org/D21880

Please take a look.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.9 Release] We have branched

[Hans Wennborg via lldb-dev]

Dear everyone,

The 3.9 branch was created earlier today from trunk at r275826, after
which the trunk version was bumped to 4.0.0.

Release blockers for 3.9 are tracked by http://llvm.org/PR28600 Please
mark any bugs (new or already tracked) that you think need to be fixed
before the release as blocking this bug.

To get a change committed to the branch, first commit it to trunk as
usual, and then reply to the commit message on the mailing list with
myself and the code owner CC'd, asking for the change to be merged to
the branch.

Release notes for 3.9 should be committed directly to the branch. (Or
send me an email and I'll commit them for you.) If you (or someone you
know) made non-trivial changes in the past six months, please make
sure they are mentioned in the notes.

Please help me out in staying on top of the release by CC'ing me on
any bugs, commits, or other issues that you think may be relevant. If
I'm not CC'd, there's a large chance I will miss it.

What happens next? Once the branch is in decent shape, hopefully
within the next few days, a first release candidate will be made
available for testing.

Many thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.9 Release] Release Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

Dear testers,

3.9.0-rc1 was just tagged from the 3.9 branch at r277207.

This took a little longer than I'd hoped, but I think the branch is in
a decent state now.

There are still open merge requests and bugs, but I'd like to get the
real testing started to see where we're at.

Please build, test, and upload binaries to the sftp. Let me know how
it goes. I'll upload source, docs, and your binaries to the
pre-release page once they're ready.

Thanks,
Hans
___
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.9 Release] Release Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

On Sun, Jul 31, 2016 at 12:38 PM, Renato Golin  wrote:
> On 29 July 2016 at 23:57, Hans Wennborg via Release-testers
>  wrote:
>> There are still open merge requests and bugs, but I'd like to get the
>> real testing started to see where we're at.
>
> First wave of testing pass on ARM. Uploaded to the FTP server.
>
> Is it time to do the back-ports planned? I only have a very minor bug fix.

Sure!

Cheers,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [Release-testers] [3.9 Release] Release Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

Ouch :-(

Well, if we ever do a 3.8.2, that should be included. +Tom in case
he's maintaining a list.

On Mon, Aug 1, 2016 at 12:18 AM, Michael Kuperstein  wrote:
> The crash dump looks like it's probably PR27071.
> The bug was introduced in r261387 (which was merged into 3.8) and fixed in
> r264465 (which apparently wasn't).
>
> On Sun, Jul 31, 2016 at 3:50 PM, Bernhard Rosenkränzer
>  wrote:
>>
>> Hi,
>> On the OpenMandriva side, x86_64 passes all checks. We're having some
>> problems with other architectures though (see below):
>>
>> x86_64 succeeded, packages are here:
>> https://abf.openmandriva.org/build_lists/76792
>>
>> i586 fails to build, but this seems to be an issue with 3.8.1 (which we're
>> using to build 3.9):
>>
>> /usr/bin/clang++   -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Support -I../lib/Support
>> -Iinclude -I../include -Os  -pipe -Wformat -Werror=format-security
>> -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
>> -fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables
>> -march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1
>> -D_FILE_OFFSET_BITS=64 -fPIC -fvisibility-inlines-hidden -Wall -W
>> -Wno-unused-parameter -Wwrite-strings -Wcast-qual
>> -Wmissing-field-initializers -pedantic -Wno-long-long
>> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
>> -Werror=date-time -std=c++1y -fcolor-diagnostics -ffunction-sections
>> -fdata-sections -Os  -pipe -Wformat -Werror=format-security
>> -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4
>> -fomit-frame-pointer -mtune=atom -march=i586 -fasynchronous-unwind-tables
>> -march=i686 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1
>> -D_FILE_OFFSET_BITS=64 -MD -MT
>> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -MF
>> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o.d -o
>> lib/Support/CMakeFiles/LLVMSupport.dir/PrettyStackTrace.cpp.o -c
>> ../lib/Support/PrettyStackTrace.cpp
>> clang-3.8: ../include/llvm/CodeGen/MachineOperand.h:411: int64_t
>> llvm::MachineOperand::getImm() const: Assertion `isImm() && "Wrong
>> MachineOperand accessor"' failed.
>> #0 0xf4abd075 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
>> (/usr/lib/libLLVMSupport.so.3.8+0x95075)
>> #1 0xf4abd2c7 (/usr/lib/libLLVMSupport.so.3.8+0x952c7)
>> #2 0xf4abbbf1 llvm::sys::RunSignalHandlers()
>> (/usr/lib/libLLVMSupport.so.3.8+0x93bf1)
>> #3 0xf4abbf49 (/usr/lib/libLLVMSupport.so.3.8+0x93f49)
>> #4 0xf7714d20  0xd20 __GI_raise
>> #5 0xf7714d20
>> #6 0xf7714d20 __GI_abort (+0xd20)
>> #7 0xf4650ef0 __GI___assert_fail (/lib/libc.so.6+0x26ef0)
>> #8 0xf46520e5 __GI___assert_perror_fail (/lib/libc.so.6+0x280e5)
>> #9 0xf464b126 (/lib/libc.so.6+0x21126)
>> #10 0xf464b162 llvm::X86InstrInfo::getSPAdjust(llvm::MachineInstr
>> const*) const (/lib/libc.so.6+0x21162)
>> #11 0xf65a0db6 (/usr/lib/libLLVMX86CodeGen.so.3.8+0x30db6)
>> #12 0xf667640d (/usr/lib/libLLVMX86CodeGen.so.3.8+0x10640d)
>> #13 0xf61029dc
>> llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
>> (/usr/lib/libLLVMCodeGen.so.3.8+0x1739dc)
>> #14 0xf6105002 llvm::FPPassManager::runOnFunction(llvm::Function&)
>> (/usr/lib/libLLVMCodeGen.so.3.8+0x176002)
>> #15 0xf60ab337 llvm::FPPassManager::runOnModule(llvm::Module&)
>> (/usr/lib/libLLVMCodeGen.so.3.8+0x11c337)
>> #16 0xf50d7e6f llvm::legacy::PassManagerImpl::run(llvm::Module&)
>> (/usr/lib/libLLVMCore.so.3.8+0x19de6f)
>> #17 0xf50d816b llvm::legacy::PassManager::run(llvm::Module&)
>> (/usr/lib/libLLVMCore.so.3.8+0x19e16b)
>> #18 0xf50d857f clang::EmitBackendOutput(clang::DiagnosticsEngine&,
>> clang::CodeGenOptions const&, clang::TargetOptions const&,
>> clang::LangOptions const&, llvm::StringRef, llvm::Module*,
>> clang::BackendAction, llvm::raw_pwrite_stream*)
>> (/usr/lib/libLLVMCore.so.3.8+0x19e57f)
>> #19 0xf50d8734 (/usr/lib/libLLVMCore.so.3.8+0x19e734)
>> #20 0xf59fc72c clang::ParseAST(clang::Sema&, bool, bool)
>> (/usr/lib/libclangCodeGen.so.3.8+0x6972c)
>> #21 0xf5b2cd85 clang::ASTFrontendAction::ExecuteAction()
>> (/usr/lib/libclangCodeGen.so.3.8+0x199d85)
>> #22 0xf3b2b294 clang::CodeGenAction::ExecuteAction()
>> (/usr/lib/libclangParse.so.3.8+0x24294)
>> #23 0xf582583e clang::FrontendAction::Execute()
>> (/usr/lib/libclangFrontend.so.3.8+0x8783e)
>> #24 0xf5b2d3e1
>> clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
>> (/usr/lib/libclangCodeGen.so.3.8+0x19a3e1)
>> #25 0xf5826660
>> clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
>> (/usr/lib/libclangFrontend.so.3.8+0x88660)
>> #26 0xf58029e1 cc1_main(llvm::ArrayRef, char const*,
>> void*) (/usr/lib/libclangFrontend.so.3.8+0x649e1)
>> #27 0xf579aead main (/usr/lib/libclangFrontendTool.so.3.8+0x2ead)
>> #28 0x080

Re: [lldb-dev] [3.9 Release] Release Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

On Fri, Jul 29, 2016 at 3:57 PM, Hans Wennborg  wrote:
> Dear testers,
>
> 3.9.0-rc1 was just tagged from the 3.9 branch at r277207.
>
> This took a little longer than I'd hoped, but I think the branch is in
> a decent state now.
>
> There are still open merge requests and bugs, but I'd like to get the
> real testing started to see where we're at.
>
> Please build, test, and upload binaries to the sftp. Let me know how
> it goes. I'll upload source, docs, and your binaries to the
> pre-release page once they're ready.

Windows looked good. Binaries (sha1):
7f350f8a4903965ea9f3800f6d30a782ce86b0df  LLVM-3.9.0-rc1-win32.exe
0b40f11a8d6c1f1fb69dcf213916cf439bb326c0  LLVM-3.9.0-rc1-win64.exe
___
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.9 Release] Release Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

On Tue, Aug 2, 2016 at 3:36 AM, Renato Golin  wrote:
> On 1 August 2016 at 17:37, Hans Wennborg  wrote:
>>> Is it time to do the back-ports planned? I only have a very minor bug fix.
>>
>> Sure!
>
> Backported the v6T2/DSP patch. Now just needs to get Diana's AArch64
> fix and we're fine.

Looks like Diana's fix was merged in r277462, so it sounds like we're all good.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.9 Release] Please write release notes!

[Hans Wennborg via lldb-dev]

Dear everyone,

It's time for the release notes nagging email.

We have release notes for LLVM, Clang, clang-tools-extra, lld, and
Polly. (If there are more, please let me know.)

Most of these are pretty empty files; see e.g. the LLVM one at [1].
The internet does read these notes when we release, so please help
make them informative!

If you made any interesting changes during the past six months, or
know someone who did, please write something for the release notes.
You can commit them directly to the branch, or send a patch to me and
I'll happily commit them for you.

If you feel responsible for a particular target, e.g. X86, ARM, MIPS,
etc., please help give those release notes some love.


Here are some examples we might want to mention (thanks LLVM Weekly!).
If you're cc'd on this email, you're mentioned below.

- Dmitry, Renato: the Clang notes mention abi_tag. Do we want to
expand the text here a little? Link to the PR?

- Teresa, Mehdi: there's a "Introduction of ThinLTO [..] ping
Mehdi/Teresa before the release if not done" note, so here's the ping
:-) We should link to the blog post as well.

- Chris Bieneman, there's a "note about autoconf build having been
removed". Do you want to expand this? :-)

- Danny, George: do you want to add something about MemorySSA?

- Nico, do you want to mention clang-cl's precompiled header support?

- James, do you want to mention the removal of the CppBackend?

- Chris Dewhurst, do you want to mention soft-float SPARC support (and
potentially other SPARC improvements)?

- Benjamin, should we mention include-fixer somewhere?

Many thanks,
Hans


 [1] 
http://llvm.org/viewvc/llvm-project/llvm/branches/release_39/docs/ReleaseNotes.rst?view=markup
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.9 Release] Release Candidate 1 source and binaries available

[Hans Wennborg via lldb-dev]

Source and binaries for LLVM-3.9.0-rc1 are now available at
http://llvm.org/pre-releases/3.9.0/#rc1

Please try it out, run tests, build your favourite projects, and *file
bugs* about anything that doesn't work and needs to be fixed for the
release. Please CC me on any findings.

Thanks,
Hans
___
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.9 Release] Release Candidate 1 source and binaries available

[Hans Wennborg via lldb-dev]

On Fri, Aug 5, 2016 at 5:27 AM, Renato Golin  wrote:
> On 4 August 2016 at 19:17, Hans Wennborg via Release-testers
>  wrote:
>> Source and binaries for LLVM-3.9.0-rc1 are now available at
>> http://llvm.org/pre-releases/3.9.0/#rc1
>
> Ouch! I forgot to upload the AArch64 image! Sorry, it's there now.

It's on the web page now. Thanks!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] First hand support for musl-libc

[Hans Wennborg via lldb-dev]

On Thu, Aug 11, 2016 at 9:28 AM, Pavel Labath  wrote:
> On 10 August 2016 at 22:34, Dangling Pointer
>  wrote:
>> Thanks Pavel! I see the changes made in master branch.
>>
>>
>> By any change can these be back-ported to release38 and 39 branches? Since
>> llvm38 is the one aports is offering.
>>
>
> I think the 3.8 ship has sailed, but there still may be a chance to
> get it into 3.9.
>
> Hans, what do you make of that? (The relevant changes are r277997,
> r277999, r278000, r278001)
>
> Presumably the right approver would be Oleksiy (also in cc).

The patches seem fine to me. The one thing I'm worried about is
whether anyone is testing this stuff on the branch?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] First hand support for musl-libc

[Hans Wennborg via lldb-dev]

I've merged r277997, r277999 and r278001 to 3.9 in r278540.

Cheers,
Hans

On Fri, Aug 12, 2016 at 1:02 AM, Pavel Labath  wrote:
> Hi,
>
> I do run a basic set of tests (compile+run test suite) on linux from
> time to time, but unfortunately I don't have time to be more active in
> this. I have just completed the test on the release branch with these
> changes cherry-picked and it seems to working fine. But I certainly
> agree that the release branch could use more testing.
>
> Actually, upon closer examination, we should be able to drop one
> commit from the list - r278000 - it was just a followup cleanup to the
> previous two, and the fourth commit I mentioned still applies cleanly
> without it.
>
> cheers,
> pl
>
>
> On 11 August 2016 at 19:41, Hans Wennborg  wrote:
>> On Thu, Aug 11, 2016 at 9:28 AM, Pavel Labath  wrote:
>>> On 10 August 2016 at 22:34, Dangling Pointer
>>>  wrote:
 Thanks Pavel! I see the changes made in master branch.


 By any change can these be back-ported to release38 and 39 branches? Since
 llvm38 is the one aports is offering.

>>>
>>> I think the 3.8 ship has sailed, but there still may be a chance to
>>> get it into 3.9.
>>>
>>> Hans, what do you make of that? (The relevant changes are r277997,
>>> r277999, r278000, r278001)
>>>
>>> Presumably the right approver would be Oleksiy (also in cc).
>>
>> The patches seem fine to me. The one thing I'm worried about is
>> whether anyone is testing this stuff on the branch?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.9 Release] Release Candidate 2 has been tagged

[Hans Wennborg via lldb-dev]

Dear testers,

3.9.0-rc2 was just tagged from the 3.9 branch at r279183.

This is a release candidate in the very real sense that if nothing new
comes up, this is be what the final release looks like. There are
currently no open release blockers, and no patches in my merge-queue.

Please build, test, and upload binaries to the sftp. Let me know how
everything goes.

From this point, the branch is only open for fixing critical problems
(bad enough to warrant another test cycle) and release notes.

Thanks,
Hans
___
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.9 Release] Release Candidate 2 has been tagged

[Hans Wennborg via lldb-dev]

On Sat, Aug 20, 2016 at 2:45 PM, Sylvestre Ledru  wrote:
> Le 19/08/2016 à 03:51, Hans Wennborg via Release-testers a écrit :
>>
>> Dear testers,
>>
>> 3.9.0-rc2 was just tagged from the 3.9 branch at r279183.
>>
>> This is a release candidate in the very real sense that if nothing new
>> comes up, this is be what the final release looks like. There are
>> currently no open release blockers, and no patches in my merge-queue.
>>
>> Please build, test, and upload binaries to the sftp. Let me know how
>> everything goes.
>>
>> From this point, the branch is only open for fixing critical problems
>> (bad enough to warrant another test cycle) and release notes.
>
> Seems to work great on Debian.
> https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.9&suite=experimental
> A bit surprised to see include fixer coming in the second rc but why not.

It was already being built, tested and in the release notes, but the
binary wasn't part of the 'install' target so we just fixed that part.

> However, still the same issue on armel:
> http://lists.llvm.org/pipermail/llvm-dev/2016-August/103457.html

:-( Not a 3.9 regression though.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.9 Release] Release Candidate 2 source and binaries available

[Hans Wennborg via lldb-dev]

We're getting close to the final release. I know the schedule on the
web page says 'final' should be tagged today, but I still think it
should be possible to get there this week.

Source and binaries for LLVM-3.9.0-rc2 are now available at
http://llvm.org/pre-releases/3.9.0/#rc2

Please try it out and let me know if you find any issues.

As we're running out of time, RC2 will be a short test cycle, so if
you're planning on testing it, please don't procrastinate it :-)

Thanks,
Hans
___
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.9 Release] Release Candidate 2 source and binaries available

[Hans Wennborg via lldb-dev]

I replied on the "has been tagged" thread; I couldn't find the binary
on the sftp. Maybe you uploaded the wrong version, or in some other
folder?

On Mon, Aug 22, 2016 at 4:01 PM, Renato Golin  wrote:
> Hi Hans,
>
> I did upload the aarch64 binary, didn't you find it? Maybe I uploaded the
> wrong one?
>
> Cheers,
> Renato
>
>
> On 22 Aug 2016 7:55 p.m., "Hans Wennborg via Release-testers"
>  wrote:
>>
>> We're getting close to the final release. I know the schedule on the
>> web page says 'final' should be tagged today, but I still think it
>> should be possible to get there this week.
>>
>> Source and binaries for LLVM-3.9.0-rc2 are now available at
>> http://llvm.org/pre-releases/3.9.0/#rc2
>>
>> Please try it out and let me know if you find any issues.
>>
>> As we're running out of time, RC2 will be a short test cycle, so if
>> you're planning on testing it, please don't procrastinate it :-)
>>
>> Thanks,
>> Hans
>> ___
>> 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

[lldb-dev] [3.9 Release] Release Candidate 3 has been tagged

[Hans Wennborg via lldb-dev]

Dear testers,

3.9.0-rc3 was just tagged from the branch at r279704.

This one is very similar to rc2. These are the only new commits:

r279224 - Minor change to OpenCL release notes
r279260 - [lld] Add a note that 3.9 is a major milestone for us
r279468, r279474 - Fix gather-root.ll SLP vectorizer test to not expose UB
r279476 - [lld] Add R_386_TLS_LE as a relocation having an implicit addend.
r279471 - [msan] Disable prlimit test on glibc < 2.13
r279477 - [CloneFunction] Don't remove unrelated nodes from the CGSSC
r279647 - [SCCP] Don't delete side-effecting instructions

Please take this for a spin. If there are no hiccups, the plan is to
promote this to 'final' on Friday and ship the release early next
week.

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.9 Release] Release Candidate 3 has been tagged

[Hans Wennborg via lldb-dev]

On Wed, Aug 24, 2016 at 8:42 PM, Hans Wennborg  wrote:
> Please take this for a spin. If there are no hiccups, the plan is to
> promote this to 'final' on Friday and ship the release early next
> week.

Windows is ready:
12f424c28f22b1c60f531da2f4ba86e5cdd1ca9c  LLVM-3.9.0-rc3-win32.exe
e840f6b729d15cf9b355bd07af3a7b27d97a3bfa  LLVM-3.9.0-rc3-win64.exe

 - Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [3.9 Release] Release Candidate 3 source and binaries available

[Hans Wennborg via lldb-dev]

We're very very close to the final release. Source and binaries for
LLVM-3.9.0-rc3 are available at
http://llvm.org/pre-releases/3.9.0/#rc3

This release candidate is almost the same as rc2, with the following
additional commits:

r279224 - Minor change to OpenCL release notes
r279260 - [lld] Add a note that 3.9 is a major milestone for us
r279468, r279474 - Fix gather-root.ll SLP vectorizer test to not expose UB
r279476 - [lld] Add R_386_TLS_LE as a relocation having an implicit addend.
r279471 - [msan] Disable prlimit test on glibc < 2.13
r279477 - [CloneFunction] Don't remove unrelated nodes from the CGSSC
r279647 - [SCCP] Don't delete side-effecting instructions

We're a little bit behind schedule and there is still an open release
blocker in the Bugzilla, but I'm hopeful that we can wrap up the
release next week.

Thanks,
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.9 Release] Release Candidate 3 source and binaries available

[Hans Wennborg via lldb-dev]

On Fri, Aug 26, 2016 at 3:23 PM, Dan Walmsley via cfe-dev
 wrote:
>Are these new RC3 Windows binaries now with asserts disabled?

Yes.

Thanks,
Hans

> From: Hans Wennborg via cfe-dev
> Sent: 26 August 2016 22:30
> To: llvm-dev; cfe-dev; LLDB Dev; openmp-dev (openmp-...@lists.llvm.org)
> Cc: Release-testers
> Subject: [cfe-dev] [3.9 Release] Release Candidate 3 source and binaries
> available
>
>
>
> We're very very close to the final release. Source and binaries for
> LLVM-3.9.0-rc3 are available at
> http://llvm.org/pre-releases/3.9.0/#rc3
>
> This release candidate is almost the same as rc2, with the following
> additional commits:
>
> r279224 - Minor change to OpenCL release notes
> r279260 - [lld] Add a note that 3.9 is a major milestone for us
> r279468, r279474 - Fix gather-root.ll SLP vectorizer test to not expose UB
> r279476 - [lld] Add R_386_TLS_LE as a relocation having an implicit addend.
> r279471 - [msan] Disable prlimit test on glibc < 2.13
> r279477 - [CloneFunction] Don't remove unrelated nodes from the CGSSC
> r279647 - [SCCP] Don't delete side-effecting instructions
>
> We're a little bit behind schedule and there is still an open release
> blocker in the Bugzilla, but I'm hopeful that we can wrap up the
> release next week.
>
> Thanks,
> Hans
___
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.9 Release] Release Candidate 3 source and binaries available

[Hans Wennborg via lldb-dev]

Thanks! I've added the binaries to the page.

On Sat, Aug 27, 2016 at 5:16 PM, Vasileios Kalintiris
 wrote:
> I've uploaded the following binaries for x86_64 and MIPS/MIPSEL too:
>
> 502e2d015ed9aa6fd2fced1fc45ffb4d97c720cc  
> clang+llvm-3.9.0-rc3-mipsel-linux-gnu.tar.xz
> bc2dd5c96a094a43dd8033fdbb4fc0e4bff2d6c7  
> clang+llvm-3.9.0-rc3-mips-linux-gnu.tar.xz
> 084770c3480505e103764e9a4d8bcf65ab0debcf  
> clang+llvm-3.9.0-rc3-x86_64-linux-gnu-debian8.tar.xz
>
> No regressions and no new test failures since 3.9.0-rc2.
>
> 
> From: Release-testers [release-testers-boun...@lists.llvm.org] on behalf of 
> Hans Wennborg via Release-testers [release-test...@lists.llvm.org]
> Sent: 26 August 2016 22:29
> To: llvm-dev; cfe-dev; LLDB Dev; openmp-dev (openmp-...@lists.llvm.org)
> Cc: Release-testers
> Subject: [Release-testers] [3.9 Release] Release Candidate 3 source and 
> binaries available
>
> We're very very close to the final release. Source and binaries for
> LLVM-3.9.0-rc3 are available at
> http://llvm.org/pre-releases/3.9.0/#rc3
>
> This release candidate is almost the same as rc2, with the following
> additional commits:
>
> r279224 - Minor change to OpenCL release notes
> r279260 - [lld] Add a note that 3.9 is a major milestone for us
> r279468, r279474 - Fix gather-root.ll SLP vectorizer test to not expose UB
> r279476 - [lld] Add R_386_TLS_LE as a relocation having an implicit addend.
> r279471 - [msan] Disable prlimit test on glibc < 2.13
> r279477 - [CloneFunction] Don't remove unrelated nodes from the CGSSC
> r279647 - [SCCP] Don't delete side-effecting instructions
>
> We're a little bit behind schedule and there is still an open release
> blocker in the Bugzilla, but I'm hopeful that we can wrap up the
> release next week.
>
> Thanks,
> Hans
> ___
> 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

[lldb-dev] [3.9 Release] 'final' has been tagged

[Hans Wennborg via lldb-dev]

Dear testers,

The final version of 3.9.0 was just tagged (from the 3.9 branch at
r280312). There were no changes after rc3. This took a little longer
than expected, but on the up side that means it's had more time to be
tested.

Please build the final binaries and upload to the sftp.

For others following along: this means 3.9.0 is complete, but it will
take a few days to get the tarballs ready and uploaded to the web
page. I will send the release announcement once everything's done.

Many thanks for your hard work!
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM 3.9 Release

[Hans Wennborg via lldb-dev]

It is my pleasure to announce that LLVM 3.9.0 is now available.

Get it here: http://llvm.org/releases/download.html#3.9.0

This release is the result of the LLVM community's work over the past
six months, including ThinLTO, new libstdc++ ABI compatibility,
support for all OpenCL 2.0 and all non-offloading OpenMP 4.5 features,
clang-include-fixer, many new clang-tidy checks, significantly
improved ELF linking with lld, identical code folding and initial LTO
support in lld, as well as improved optimization, many bug fixes and
more.

See the release notes for more details:
http://llvm.org/releases/3.9.0/docs/ReleaseNotes.html
http://llvm.org/releases/3.9.0/tools/clang/docs/ReleaseNotes.html
http://llvm.org/releases/3.9.0/tools/clang/tools/extra/docs/ReleaseNotes.html
http://llvm.org/releases/3.9.0/tools/lld/docs/ReleaseNotes.html

Thanks to everyone who helped with filing, fixing and doing code
review for release blocking bugs.

Special thanks to the release testers and packagers: Dimitry Andric,
Renato Golin, Vasileios Kalintiris, Diana Picus, Ben Pope and Nikola
Smiljanic. Also thanks to Zhendong Su whose fuzz testing prevented
many bugs going into this release.

For questions or comments about this release, please contact the
community on the mailing lists. Onward to 4.0!

Cheers,
Hans
___
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.9 Release] 'final' has been tagged

[Hans Wennborg via lldb-dev]

Thanks! I've added the binaries to the web site now.

Cheers,
Hans

On Sun, Sep 4, 2016 at 5:41 AM, Vasileios Kalintiris
 wrote:
> I uploaded the binaries for MIPS, MIPSEL and the X86_64 debian8 build:
>
> 0e76e4cb45aaa0ee06076da43bbb27f6624abf14  
> clang+llvm-3.9.0-mipsel-linux-gnu.tar.xz
> 5a78496161aece73ccfc2b05edaf68bec4da9417  
> clang+llvm-3.9.0-mips-linux-gnu.tar.xz
> 56f4334f2d59613b2599fbba9017fa0609fbdf06  
> clang+llvm-3.9.0-x86_64-linux-gnu-debian8.tar.xz
>
> Everything looks good but I can't run LNT for MIPSEL because of a network 
> problem. I'll run it tomorrow and I'll report back *if* there's any 
> unexpected problem.
>
> - V. Kalintiris
> 
> From: Release-testers [release-testers-boun...@lists.llvm.org] on behalf of 
> Hans Wennborg via Release-testers [release-test...@lists.llvm.org]
> Sent: 01 September 2016 00:49
> To: Release-testers
> Cc: llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); LLDB Dev
> Subject: [Release-testers] [3.9 Release] 'final' has been tagged
>
> Dear testers,
>
> The final version of 3.9.0 was just tagged (from the 3.9 branch at
> r280312). There were no changes after rc3. This took a little longer
> than expected, but on the up side that means it's had more time to be
> tested.
>
> Please build the final binaries and upload to the sftp.
>
> For others following along: this means 3.9.0 is complete, but it will
> take a few days to get the tarballs ready and uploaded to the web
> page. I will send the release announcement once everything's done.
>
> Many thanks for your hard work!
> Hans
> ___
> 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] lldb-3.8.1 prebuilt binary for windows7

[Hans Wennborg via lldb-dev]

The snapshots are built with the script in
utils/release/build_llvm_package.bat. It's currently passing
-DLLDB_RELOCATABLE_PYTHON=1 and  -DPYTHON_HOME=.

I was planning on trying to build a new snapshot today and can add
-DLLDB_DEFAULT_PYTHON_HOME if you think that will help.

On Mon, Nov 28, 2016 at 9:51 AM, Zachary Turner  wrote:
> So it sounds like you're saying that in order for Python support to work as
> part of an LLDB shipped in the installer, we need to do set 3 variables at
> CMake time.
>
> 1) -DLLDB_RELOCATABLE_PYTHON=TRUE
> 2) -DPYTHON_HOME = 
> 3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE
>
> Now because of #3, the lldb shipped in the installer will use the PYTHONHOME
> system environment variable to locate python, which must point to a valid
> Python 3.5 installation.  Is this correct?
>
> On Mon, Nov 28, 2016 at 9:35 AM Ted Woodward 
> wrote:
>>
>> Windows has no concept of a default python installation, and I can’t be
>> sure what version of python my users have, if any, so I need to solve 2
>> problems:
>>
>> 1)  Where is python when I’m building?
>>
>> 2)  Where is python when I’m running?
>>
>>
>>
>> To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to my
>> python installation (on our buildbots, c:/python351).
>>
>>
>>
>> #2 only needs to be solved if the machine you’re running on doesn’t have
>> the same python installation, in PYTHON_HOME above. To do that, I’ve added
>> code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a macro
>> down to InitializePythonHome in
>> source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp, and
>> call Py_SetPythonHome with it. My installations have the python dll and
>> python library directory. We put the library in /lib/python35 and
>> the dll in /bin.
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>>
>>
>>
>> From: Zachary Turner [mailto:ztur...@google.com]
>> Sent: Wednesday, November 23, 2016 12:40 PM
>> To: Vadim Chugunov 
>> Cc: Reid Kleckner ; Hans Wennborg ;
>> LLDB ; Ted Woodward 
>> Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
>>
>>
>>
>> I believe the way to fix this is going to be building LLDB for the
>> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
>>
>>
>>
>> +Ted, since I believe he is one of the few people currently using this
>> flag.
>>
>> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov  wrote:
>>
>> This is still broken in the October snapshot.   Do you know which script
>> is used to build the Windows installer?
>>
>>
>>
>> On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner 
>> wrote:
>>
>> I think it is a problem with the way we built lldb.  I will look into what
>> additional steps we need to take when making the prebuilt binary so that it
>> works next time.
>>
>>
>>
>> On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov  wrote:
>>
>> Nope, that didn't help.
>>
>>
>>
>> On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner 
>> wrote:
>>
>> I may know what this is.  Can you try setting PYTHONPATH though to point
>> to your Python 3.5 installation though and see if it fixes it?  (I don't
>> think it will, but let's try anyway)
>>
>>
>>
>> On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov  wrote:
>>
>> It outputs 'c:\Program Files (x86)\LLVM\lib\site-packages', however the
>> 'site-packages' directory does not exist.  Nor do I see '_lldb.pyd' anywhere
>> else.
>>
>> 'script import lldb' also fails, of course.
>>
>>
>>
>> On Tue, Oct 11, 2016 at 4:01 PM, Zachary Turner 
>> wrote:
>>
>> He said he did, so I don't know.  Vadim, can you elaborate?  When you run
>> `lldb -P` from the command line, what do you see?
>>
>>
>>
>> On Tue, Oct 11, 2016 at 4:00 PM Reid Kleckner via lldb-dev
>>  wrote:
>>
>> I imagine that Hans doesn't have Python 3 installed on his system, so LLDB
>> didn't autoconfigure with Python support.
>>
>>
>>
>> On Sun, Oct 9, 2016 at 1:07 PM, Vadim Chugunov via lldb-dev
>>  wrote:
>>
>> > Does the 4.0 binary not work for you? It is the first release that
>> > contains prebuilt lldb binary.
>>
>>
>>
>> Looks like the Python API is not included though.   Do you know why it was
>> left out?
>>
>>
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
>>
>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [4.0 Release] Schedule and call for testers

[Hans Wennborg via lldb-dev]

Dear everyone,

There's still plenty of time left, but I'd like to get the schedule
set before folks start disappearing for the holidays.

Note that this release will also switch us to the new versioning
scheme where the major version is incremented for each major release
(i.e., when the 4.0 branch is created, trunk will become 5.0).

If you'd like to help providing binaries and testing for your
favourite platform, please subscribe to the release-testers mailing
list [1].

I propose the following schedule for the 4.0 release:

- 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter.

- 1 February: Tag RC2. All lose ends should have been tied up by now.

- 21 February: Final tag. Binaries and release announcement a few days later.

Unless there are any objections, I'll post this on the web page soon.

Cheers,
Hans


  [1] http://lists.llvm.org/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] lldb-3.8.1 prebuilt binary for windows7

[Hans Wennborg via lldb-dev]

Is anyone working on this?

I'm happy to include LLDB in the installer, but I'm really not the
best person to be debugging it.

If more files need to be included in the install, that's configured in
the CMake files (what's installed by the 'install' build target is
also what ends up going into the installer). If it needs more build
flags, patches to build_llvm_package.bat are welsome.

Thanks,
Hans

On Mon, Nov 28, 2016 at 10:17 AM, Zachary Turner  wrote:
> I overlooked that part of it, but yes that is another separate issue.  (BTW,
> _lldb.pyd is simply a symlink to liblldb.dll).
>
> In any case, yea I think the entire lib/site-packages folder needs to be
> included.
>
> On Mon, Nov 28, 2016 at 10:15 AM Vadim Chugunov  wrote:
>>
>> Please correct me if I'm wrong, but isn't the issue here that LLDB's
>> Python support files don't get packaged into the Windows installer?   Does
>> packaging them somehow depend on knowing what the Python installation path
>> is?
>>
>> On Mon, Nov 28, 2016 at 10:09 AM, Hans Wennborg  wrote:
>>>
>>> The snapshots are built with the script in
>>> utils/release/build_llvm_package.bat. It's currently passing
>>> -DLLDB_RELOCATABLE_PYTHON=1 and  -DPYTHON_HOME=.
>>>
>>> I was planning on trying to build a new snapshot today and can add
>>> -DLLDB_DEFAULT_PYTHON_HOME if you think that will help.
>>>
>>> On Mon, Nov 28, 2016 at 9:51 AM, Zachary Turner 
>>> wrote:
>>> > So it sounds like you're saying that in order for Python support to
>>> > work as
>>> > part of an LLDB shipped in the installer, we need to do set 3 variables
>>> > at
>>> > CMake time.
>>> >
>>> > 1) -DLLDB_RELOCATABLE_PYTHON=TRUE
>>> > 2) -DPYTHON_HOME = 
>>> > 3) -DLLDB_DEFAULT_PYTHON_HOME=TRUE
>>> >
>>> > Now because of #3, the lldb shipped in the installer will use the
>>> > PYTHONHOME
>>> > system environment variable to locate python, which must point to a
>>> > valid
>>> > Python 3.5 installation.  Is this correct?
>>> >
>>> > On Mon, Nov 28, 2016 at 9:35 AM Ted Woodward
>>> > 
>>> > wrote:
>>> >>
>>> >> Windows has no concept of a default python installation, and I can’t
>>> >> be
>>> >> sure what version of python my users have, if any, so I need to solve
>>> >> 2
>>> >> problems:
>>> >>
>>> >> 1)  Where is python when I’m building?
>>> >>
>>> >> 2)  Where is python when I’m running?
>>> >>
>>> >>
>>> >>
>>> >> To solve #1, I set LLDB_RELOCATABLE_PYTHON to TRUE, and PYTHON_HOME to
>>> >> my
>>> >> python installation (on our buildbots, c:/python351).
>>> >>
>>> >>
>>> >>
>>> >> #2 only needs to be solved if the machine you’re running on doesn’t
>>> >> have
>>> >> the same python installation, in PYTHON_HOME above. To do that, I’ve
>>> >> added
>>> >> code to set a cmake path LLDB_DEFAULT_PYTHONHOME, which I pass as a
>>> >> macro
>>> >> down to InitializePythonHome in
>>> >> source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp,
>>> >> and
>>> >> call Py_SetPythonHome with it. My installations have the python dll
>>> >> and
>>> >> python library directory. We put the library in /lib/python35
>>> >> and
>>> >> the dll in /bin.
>>> >>
>>> >> --
>>> >>
>>> >> Qualcomm Innovation Center, Inc.
>>> >>
>>> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>>> >> a
>>> >> Linux Foundation Collaborative Project
>>> >>
>>> >>
>>> >>
>>> >> From: Zachary Turner [mailto:ztur...@google.com]
>>> >> Sent: Wednesday, November 23, 2016 12:40 PM
>>> >> To: Vadim Chugunov 
>>> >> Cc: Reid Kleckner ; Hans Wennborg ;
>>> >> LLDB ; Ted Woodward
>>> >> 
>>> >> Subject: Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7
>>> >>
>>> >>
>>> >>
>>> >> I believe the way to fix this is going to be building LLDB for the
>>> >> installer with LLDB_RELOCATABLE_PYTHON=1 at CMake time
>>> >>
>>> >>
>>> >>
>>> >> +Ted, since I believe he is one of the few people currently using this
>>> >> flag.
>>> >>
>>> >> On Wed, Nov 23, 2016 at 10:36 AM Vadim Chugunov 
>>> >> wrote:
>>> >>
>>> >> This is still broken in the October snapshot.   Do you know which
>>> >> script
>>> >> is used to build the Windows installer?
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Oct 11, 2016 at 6:24 PM, Zachary Turner 
>>> >> wrote:
>>> >>
>>> >> I think it is a problem with the way we built lldb.  I will look into
>>> >> what
>>> >> additional steps we need to take when making the prebuilt binary so
>>> >> that it
>>> >> works next time.
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Oct 11, 2016 at 6:20 PM Vadim Chugunov 
>>> >> wrote:
>>> >>
>>> >> Nope, that didn't help.
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Oct 11, 2016 at 5:16 PM, Zachary Turner 
>>> >> wrote:
>>> >>
>>> >> I may know what this is.  Can you try setting PYTHONPATH though to
>>> >> point
>>> >> to your Python 3.5 installation though and see if it fixes it?  (I
>>> >> don't
>>> >> think it will, but let's try anyway)
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Oct 11, 2016 at 4:59 PM Vadim Chugunov 
>>> >> wrote:
>>> >>
>>> >> It outputs 'c:\Program Files (x86)\LLVM\lib\site-pack

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

[Hans Wennborg via lldb-dev]

On Mon, Dec 5, 2016 at 10:42 AM, Dimitry Andric  wrote:
> On 05 Dec 2016, at 19:26, Hans Wennborg via Openmp-dev 
>  wrote:
>>
>> There's still plenty of time left, but I'd like to get the schedule
>> set before folks start disappearing for the holidays.
>>
>> Note that this release will also switch us to the new versioning
>> scheme where the major version is incremented for each major release
>> (i.e., when the 4.0 branch is created, trunk will become 5.0).
>
> Maybe I didn't pay enough attention, but where is the general outline
> for this versioning scheme documented?  And are we still going to do
> 4.1, 4.2, etc?

There was a long discussion around the time when the 3.9 branch was
created. I'm planning on writing a blog post to make sure everyone is
up to date.

The idea is that Tom's stable releases will keep incrementing the
"patch" part of the version numbers, just as today, so they would be
4.0.1, 4.0.2, etc.

>> If you'd like to help providing binaries and testing for your
>> favourite platform, please subscribe to the release-testers mailing
>> list [1].
>>
>> I propose the following schedule for the 4.0 release:
>>
>> - 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter.
>>
>> - 1 February: Tag RC2. All lose ends should have been tied up by now.
>>
>> - 21 February: Final tag. Binaries and release announcement a few days later.
>>
>> Unless there are any objections, I'll post this on the web page soon.
>
> Note that this is a pretty close follow-up to the 3.9.1 release.  There
> is a minor risk of "release burn-out" here... :)

Hopefully 3.9.1 will be done some time before 4.0.0 starts, otherwise
I agree that's not very good for the testers. I don't want to change
the schedule of the major releases though, as we've been on a nice
predictible 6-month cycle for a while now.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

On Mon, Dec 5, 2016 at 11:00 AM, Renato Golin  wrote:
> On 5 December 2016 at 18:56, Hans Wennborg via Release-testers
>  wrote:
>> The idea is that Tom's stable releases will keep incrementing the
>> "patch" part of the version numbers, just as today, so they would be
>> 4.0.1, 4.0.2, etc.
>
> Hum, this looks weird. I was under the impression that we'd do 4.1, 4.2 
> instead.

I'd like to avoid 4.1 because of the potential for confusion about
whether it's a major release (as it would have been under the old
scheme) or a patch release.

> Otherwise, it'll be:
>
> * 3.9.0
> * 3.9.1
> * 4.0.0
> * 4.0.1
> * 5.0.0
> * 5.0.1
>
> With a totally redundant zero in the middle.

Yes, it has a redundant zero in the middle, but I don't think that's a
terrible thing, and it's very clear what the version number means.

The alternative would be:

3.9.0
3.9.1
4.0.0
4.1.0 <-- Can't tell from the version number what kind of release this is.

> Unless we're planning to extend the maintenance of the 5.x branch and
> release 5.1.0 *after* 6.0.0 is out, which would be a major change in
> how we release LLVM. I don't think that's the plan.

Right, not planning to do that.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb-3.8.1 prebuilt binary for windows7

[Hans Wennborg via lldb-dev]

The only thing needed to build the installer should be having NSIS
installed and building the "package" target generated by CMake. The
other prerequisites are mostly for building the visual studio
clang-format plugin.

Having said that, you don't even have to build the installer to see
what goes in it. Just building the "install" target generated by CMake
will install the same set of files.

I'm not sure how LLDB's cmake files are organized, but in the end
what's required is invoking the install() command:
https://cmake.org/cmake/help/v3.0/command/install.html  In LLVM, this
is done automatically by macros such as add_llvm_executale, etc.

On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov  wrote:
> Hi Hans,
>
> I'd love to help, but I don't have half the tools that
> build_llvm_package.bat requires installed on my machine.  My setup is to
> build llvm with msbuild.   Is it possible to build the installer this way
> too?
>
> Can you point me to the specific CMake source that determines what's
> included in the package?   At a glance, everything from
> %LLVM%/lib/site-packages is missing.
>
> Vadim
>
> On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg  wrote:
>>
>> Is anyone working on this?
>>
>> I'm happy to include LLDB in the installer, but I'm really not the
>> best person to be debugging it.
>>
>> If more files need to be included in the install, that's configured in
>> the CMake files (what's installed by the 'install' build target is
>> also what ends up going into the installer). If it needs more build
>> flags, patches to build_llvm_package.bat are welsome.
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

On Mon, Dec 5, 2016 at 12:02 PM, Renato Golin  wrote:
> On 5 December 2016 at 19:56, Hans Wennborg  wrote:
>> I'd like to avoid 4.1 because of the potential for confusion about
>> whether it's a major release (as it would have been under the old
>> scheme) or a patch release.
>
> But if the versioning scheme is different, users will have to
> understand what it means anyway.
>
> Until now we had a weird and very unique logic, and we're moving to a
> more sensible logic, because it's similar to what some other projects
> are doing.
>
> I can see as much confusion from 4.0.1 -> 5.0.0 than by having a 4.1
> that used to be weird before.
>
> After a few releases everything will be clear anyway... I really don't
> want to make the foreseeable future weird again to avoid a potential
> misunderstanding for one or two releases.
>
> Let's just be brutally clear in all release communications and
> hopefully people will understand.
>
>
>> The alternative would be:
>>
>> 3.9.0
>> 3.9.1
>> 4.0.0
>> 4.1.0 <-- Can't tell from the version number what kind of release this is.
>
> No, that has a redundant zero, too.
>
> The alternative is:
>
> 3.9.0
> 3.9.1
> 4.0
> 4.1
> 5.0
> 5.1

I'm worried that users will, with some reason, think that the 4.1 and
5.1 releases are the same kind as 2.1 and 3.1 :-/
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

On Mon, Dec 5, 2016 at 12:29 PM, Renato Golin  wrote:
> On 5 December 2016 at 20:07, Hans Wennborg  wrote:
>> I'm worried that users will, with some reason, think that the 4.1 and
>> 5.1 releases are the same kind as 2.1 and 3.1 :-/
>
> IMO, this is too small of a worry to encumber us for the rest of our
> release days with silly zeroes.

For me, it's a big worry, and I'm positive lots of developers (and any
code trying to parse our version numbers) would be confused by
dropping it.

I don't think having a redundant zero in the middle is a big problem:
we used to make minor releases but now we don't, so it stays at zero.
(And if for some reason we'd want to do one in the future, we could.)

This is the scheme we arrived at at the end of the great version
number discussion this summer, and I don't see any reason to change it
now.

> I'd rather be redundantly explicit for the next year, than carry that
> burden for the next 5 (or more).

Sure, if we think this is terribly annoying in the future and we
decide dropping the unused "minor" part of our version number is the
best thing, we could attempt it at that point. I'm not doing anything
now that would make that harder.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[Hans Wennborg via lldb-dev]

It's not atomic, but I specify a specific revision when creating the
branch, across all projects, so it has the same effect.

When creating tags on the branch I just create it on tip-of-tree since
the branch is low traffic.

Does that address your concerns?

On Tue, Dec 6, 2016 at 3:31 AM, NAKAMURA Takumi  wrote:
> I hope you could branch and tag to projects atomically. Are you able?
>
> On Tue, Dec 6, 2016 at 3:26 AM Hans Wennborg via Release-testers
>  wrote:
>>
>> Dear everyone,
>>
>> There's still plenty of time left, but I'd like to get the schedule
>> set before folks start disappearing for the holidays.
>>
>> Note that this release will also switch us to the new versioning
>> scheme where the major version is incremented for each major release
>> (i.e., when the 4.0 branch is created, trunk will become 5.0).
>>
>> If you'd like to help providing binaries and testing for your
>> favourite platform, please subscribe to the release-testers mailing
>> list [1].
>>
>> I propose the following schedule for the 4.0 release:
>>
>> - 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter.
>>
>> - 1 February: Tag RC2. All lose ends should have been tied up by now.
>>
>> - 21 February: Final tag. Binaries and release announcement a few days
>> later.
>>
>> Unless there are any objections, I'll post this on the web page soon.
>>
>> Cheers,
>> Hans
>>
>>
>>   [1] http://lists.llvm.org/mailman/listinfo/release-testers
>> ___
>> 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] [4.0 Release] Schedule and call for testers

[Hans Wennborg via lldb-dev]

On Mon, Dec 5, 2016 at 10:26 AM, Hans Wennborg  wrote:
> Dear everyone,
>
> There's still plenty of time left, but I'd like to get the schedule
> set before folks start disappearing for the holidays.
>
> Note that this release will also switch us to the new versioning
> scheme where the major version is incremented for each major release
> (i.e., when the 4.0 branch is created, trunk will become 5.0).

There's now a blog post about the new scheme here:
http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html

> I propose the following schedule for the 4.0 release:
>
> - 12 January 2017: Create the 4.0 branch. RC1 tagged soon thereafter.
>
> - 1 February: Tag RC2. All lose ends should have been tied up by now.
>
> - 21 February: Final tag. Binaries and release announcement a few days later.
>
> Unless there are any objections, I'll post this on the web page soon.

I've updated the web page.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [4.0.0 Release] One week to the branch

[Hans Wennborg via lldb-dev]

This is just a quick reminder that branching for the upcoming release
is scheduled for one week from now, 12 January 2017. Please try to
avoid disruptive changes right before the branch.

The full schedule was posted in a previous email [1] and also under
"Upcoming Releases" on http://llvm.org/

Note that when the branch happens, the trunk version will become 5.0.0
as per the new versioning scheme [2].

Cheers,
Hans

 [1] http://lists.llvm.org/pipermail/llvm-dev/2016-December/107805.html
 [2] http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Hans Wennborg via lldb-dev]

Vadim, it looks like your change was committed in r291291, and I've
built a new snapshot today which includes it. Can you give it a try
and see if everything works?

Cheers,
Hans

On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner  wrote:
> I will commit it, in the meantime can you request commit access so that any
> future patches you can commit?
>
> On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov  wrote:
>>
>> Thanks!
>>
>> Would anyone be so kind to commit that?
>>
>> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner 
>> wrote:
>>>
>>> Sorry, a combination of national holidays and extended vacations happened
>>> and this fell off my radar.  lgtm
>>>
>>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov  wrote:

 Zachary,
 Can you please take a look at that change?
 (https://reviews.llvm.org/D27476)

 It'll be sad if another snapshot build gets published with broken lldb.
 :(


 On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov 
 wrote:
>
> This seems to work: https://reviews.llvm.org/D27476
>
> On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg 
> wrote:
>>
>> The only thing needed to build the installer should be having NSIS
>> installed and building the "package" target generated by CMake. The
>> other prerequisites are mostly for building the visual studio
>> clang-format plugin.
>>
>> Having said that, you don't even have to build the installer to see
>> what goes in it. Just building the "install" target generated by CMake
>> will install the same set of files.
>>
>> I'm not sure how LLDB's cmake files are organized, but in the end
>> what's required is invoking the install() command:
>> https://cmake.org/cmake/help/v3.0/command/install.html  In LLVM, this
>> is done automatically by macros such as add_llvm_executale, etc.
>>
>> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov 
>> wrote:
>> > Hi Hans,
>> >
>> > I'd love to help, but I don't have half the tools that
>> > build_llvm_package.bat requires installed on my machine.  My setup
>> > is to
>> > build llvm with msbuild.   Is it possible to build the installer
>> > this way
>> > too?
>> >
>> > Can you point me to the specific CMake source that determines what's
>> > included in the package?   At a glance, everything from
>> > %LLVM%/lib/site-packages is missing.
>> >
>> > Vadim
>> >
>> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg 
>> > wrote:
>> >>
>> >> Is anyone working on this?
>> >>
>> >> I'm happy to include LLDB in the installer, but I'm really not the
>> >> best person to be debugging it.
>> >>
>> >> If more files need to be included in the install, that's configured
>> >> in
>> >> the CMake files (what's installed by the 'install' build target is
>> >> also what ends up going into the installer). If it needs more build
>> >> flags, patches to build_llvm_package.bat are welsome.
>> >
>> >
>> >
>
>

>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Hans Wennborg via lldb-dev]

I'll do another snapshot maybe next week or the week after. You can
also ping me if you want it sooner or later.

We're kicking off the release process for 4.0.0 on Thursday. I don't
fully understand the problem here, but if there's some way to work
around it and get lldb into good shape for the 4.0.0 installer, that
would be great.

Thanks,
Hans

On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov  wrote:
> This appears to be a SWIG bug: https://github.com/swig/swig/issues/769
>
> On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov  wrote:
>>
>> It worked!
>>
>> ...but not before I set PYTHONPATH=C:\Program Files
>> (x86)\LLVM\lib\site-packages\lldb
>> Without that, it couldn't find the _lldb module, so we are not quite out
>> of the woods yet.
>>
>> When are you planning to make the next snapshot build?
>> Thanks!
>>
>>
>> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg  wrote:
>>>
>>> Vadim, it looks like your change was committed in r291291, and I've
>>> built a new snapshot today which includes it. Can you give it a try
>>> and see if everything works?
>>>
>>> Cheers,
>>> Hans
>>>
>>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner 
>>> wrote:
>>> > I will commit it, in the meantime can you request commit access so that
>>> > any
>>> > future patches you can commit?
>>> >
>>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov 
>>> > wrote:
>>> >>
>>> >> Thanks!
>>> >>
>>> >> Would anyone be so kind to commit that?
>>> >>
>>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner 
>>> >> wrote:
>>> >>>
>>> >>> Sorry, a combination of national holidays and extended vacations
>>> >>> happened
>>> >>> and this fell off my radar.  lgtm
>>> >>>
>>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov 
>>> >>> wrote:
>>> 
>>>  Zachary,
>>>  Can you please take a look at that change?
>>>  (https://reviews.llvm.org/D27476)
>>> 
>>>  It'll be sad if another snapshot build gets published with broken
>>>  lldb.
>>>  :(
>>> 
>>> 
>>>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov 
>>>  wrote:
>>> >
>>> > This seems to work: https://reviews.llvm.org/D27476
>>> >
>>> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg 
>>> > wrote:
>>> >>
>>> >> The only thing needed to build the installer should be having NSIS
>>> >> installed and building the "package" target generated by CMake.
>>> >> The
>>> >> other prerequisites are mostly for building the visual studio
>>> >> clang-format plugin.
>>> >>
>>> >> Having said that, you don't even have to build the installer to
>>> >> see
>>> >> what goes in it. Just building the "install" target generated by
>>> >> CMake
>>> >> will install the same set of files.
>>> >>
>>> >> I'm not sure how LLDB's cmake files are organized, but in the end
>>> >> what's required is invoking the install() command:
>>> >> https://cmake.org/cmake/help/v3.0/command/install.html  In LLVM,
>>> >> this
>>> >> is done automatically by macros such as add_llvm_executale, etc.
>>> >>
>>> >> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov
>>> >> 
>>> >> wrote:
>>> >> > Hi Hans,
>>> >> >
>>> >> > I'd love to help, but I don't have half the tools that
>>> >> > build_llvm_package.bat requires installed on my machine.  My
>>> >> > setup
>>> >> > is to
>>> >> > build llvm with msbuild.   Is it possible to build the installer
>>> >> > this way
>>> >> > too?
>>> >> >
>>> >> > Can you point me to the specific CMake source that determines
>>> >> > what's
>>> >> > included in the package?   At a glance, everything from
>>> >> > %LLVM%/lib/site-packages is missing.
>>> >> >
>>> >> > Vadim
>>> >> >
>>> >> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg
>>> >> > 
>>> >> > wrote:
>>> >> >>
>>> >> >> Is anyone working on this?
>>> >> >>
>>> >> >> I'm happy to include LLDB in the installer, but I'm really not
>>> >> >> the
>>> >> >> best person to be debugging it.
>>> >> >>
>>> >> >> If more files need to be included in the install, that's
>>> >> >> configured
>>> >> >> in
>>> >> >> the CMake files (what's installed by the 'install' build target
>>> >> >> is
>>> >> >> also what ends up going into the installer). If it needs more
>>> >> >> build
>>> >> >> flags, patches to build_llvm_package.bat are welsome.
>>> >> >
>>> >> >
>>> >> >
>>> >
>>> >
>>> 
>>> >>
>>> >
>>
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prebuilt binary for Windows

[Hans Wennborg via lldb-dev]

I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
Please let me know if that works.

On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner  wrote:
> It sounds like the solution to the problem is to downgrade SWIG on the build
> machine.  If it's using version 3.0.9 or higher, just use whatever the last
> version before that is.  3.0.8, for example.
>
> At least there's a good workaround in the interim (i.e. setting PYTHONPATH)
>
> On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg  wrote:
>>
>> I'll do another snapshot maybe next week or the week after. You can
>> also ping me if you want it sooner or later.
>>
>> We're kicking off the release process for 4.0.0 on Thursday. I don't
>> fully understand the problem here, but if there's some way to work
>> around it and get lldb into good shape for the 4.0.0 installer, that
>> would be great.
>>
>> Thanks,
>> Hans
>>
>> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov  wrote:
>> > This appears to be a SWIG bug: https://github.com/swig/swig/issues/769
>> >
>> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
>> > wrote:
>> >>
>> >> It worked!
>> >>
>> >> ...but not before I set PYTHONPATH=C:\Program Files
>> >> (x86)\LLVM\lib\site-packages\lldb
>> >> Without that, it couldn't find the _lldb module, so we are not quite
>> >> out
>> >> of the woods yet.
>> >>
>> >> When are you planning to make the next snapshot build?
>> >> Thanks!
>> >>
>> >>
>> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
>> >> wrote:
>> >>>
>> >>> Vadim, it looks like your change was committed in r291291, and I've
>> >>> built a new snapshot today which includes it. Can you give it a try
>> >>> and see if everything works?
>> >>>
>> >>> Cheers,
>> >>> Hans
>> >>>
>> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner 
>> >>> wrote:
>> >>> > I will commit it, in the meantime can you request commit access so
>> >>> > that
>> >>> > any
>> >>> > future patches you can commit?
>> >>> >
>> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov 
>> >>> > wrote:
>> >>> >>
>> >>> >> Thanks!
>> >>> >>
>> >>> >> Would anyone be so kind to commit that?
>> >>> >>
>> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner
>> >>> >> 
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> Sorry, a combination of national holidays and extended vacations
>> >>> >>> happened
>> >>> >>> and this fell off my radar.  lgtm
>> >>> >>>
>> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov 
>> >>> >>> wrote:
>> >>> 
>> >>>  Zachary,
>> >>>  Can you please take a look at that change?
>> >>>  (https://reviews.llvm.org/D27476)
>> >>> 
>> >>>  It'll be sad if another snapshot build gets published with broken
>> >>>  lldb.
>> >>>  :(
>> >>> 
>> >>> 
>> >>>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov
>> >>>  
>> >>>  wrote:
>> >>> >
>> >>> > This seems to work: https://reviews.llvm.org/D27476
>> >>> >
>> >>> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg
>> >>> > 
>> >>> > wrote:
>> >>> >>
>> >>> >> The only thing needed to build the installer should be having
>> >>> >> NSIS
>> >>> >> installed and building the "package" target generated by CMake.
>> >>> >> The
>> >>> >> other prerequisites are mostly for building the visual studio
>> >>> >> clang-format plugin.
>> >>> >>
>> >>> >> Having said that, you don't even have to build the installer to
>> >>> >> see
>> >>> >> what goes in it. Just building the "install" target generated
>> >>> >> by
>> >>> >> CMake
>> >>> >> will install the same set of files.
>> >>> >>
>> >>> >> I'm not sure how LLDB's cmake files are organized, but in the
>> >>> >> end
>> >>> >> what's required is invoking the install() command:
>> >>> >> https://cmake.org/cmake/help/v3.0/command/install.html  In
>> >>> >> LLVM,
>> >>> >> this
>> >>> >> is done automatically by macros such as add_llvm_executale,
>> >>> >> etc.
>> >>> >>
>> >>> >> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov
>> >>> >> 
>> >>> >> wrote:
>> >>> >> > Hi Hans,
>> >>> >> >
>> >>> >> > I'd love to help, but I don't have half the tools that
>> >>> >> > build_llvm_package.bat requires installed on my machine.  My
>> >>> >> > setup
>> >>> >> > is to
>> >>> >> > build llvm with msbuild.   Is it possible to build the
>> >>> >> > installer
>> >>> >> > this way
>> >>> >> > too?
>> >>> >> >
>> >>> >> > Can you point me to the specific CMake source that determines
>> >>> >> > what's
>> >>> >> > included in the package?   At a glance, everything from
>> >>> >> > %LLVM%/lib/site-packages is missing.
>> >>> >> >
>> >>> >> > Vadim
>> >>> >> >
>> >>> >> > On Mon, Dec 5, 2016 at 10:41 AM, Hans Wennborg
>> >>> >> > 
>> >>> >> > wrote:
>> >>> >> >>
>> >>> >> >> Is anyone working on this?
>> >>> >> >>
>> >>> >> >> I'm happy to include LLDB in the installer, but I'm r

Re: [lldb-dev] Prebuilt binary for Windows

[Hans Wennborg via lldb-dev]

Great! Thanks for pushing this.

On Tue, Jan 10, 2017 at 7:00 PM, Vadim Chugunov  wrote:
> Yes, the new build works!
>
> On Tue, Jan 10, 2017 at 6:20 PM, Hans Wennborg  wrote:
>>
>> I've downgraded my swig to 3.0.8 and built a new snapshot (r291454).
>> Please let me know if that works.
>>
>> On Tue, Jan 10, 2017 at 10:14 AM, Zachary Turner 
>> wrote:
>> > It sounds like the solution to the problem is to downgrade SWIG on the
>> > build
>> > machine.  If it's using version 3.0.9 or higher, just use whatever the
>> > last
>> > version before that is.  3.0.8, for example.
>> >
>> > At least there's a good workaround in the interim (i.e. setting
>> > PYTHONPATH)
>> >
>> > On Tue, Jan 10, 2017 at 10:06 AM Hans Wennborg 
>> > wrote:
>> >>
>> >> I'll do another snapshot maybe next week or the week after. You can
>> >> also ping me if you want it sooner or later.
>> >>
>> >> We're kicking off the release process for 4.0.0 on Thursday. I don't
>> >> fully understand the problem here, but if there's some way to work
>> >> around it and get lldb into good shape for the 4.0.0 installer, that
>> >> would be great.
>> >>
>> >> Thanks,
>> >> Hans
>> >>
>> >> On Mon, Jan 9, 2017 at 10:40 PM, Vadim Chugunov 
>> >> wrote:
>> >> > This appears to be a SWIG bug:
>> >> > https://github.com/swig/swig/issues/769
>> >> >
>> >> > On Mon, Jan 9, 2017 at 9:14 PM, Vadim Chugunov 
>> >> > wrote:
>> >> >>
>> >> >> It worked!
>> >> >>
>> >> >> ...but not before I set PYTHONPATH=C:\Program Files
>> >> >> (x86)\LLVM\lib\site-packages\lldb
>> >> >> Without that, it couldn't find the _lldb module, so we are not quite
>> >> >> out
>> >> >> of the woods yet.
>> >> >>
>> >> >> When are you planning to make the next snapshot build?
>> >> >> Thanks!
>> >> >>
>> >> >>
>> >> >> On Mon, Jan 9, 2017 at 3:48 PM, Hans Wennborg 
>> >> >> wrote:
>> >> >>>
>> >> >>> Vadim, it looks like your change was committed in r291291, and I've
>> >> >>> built a new snapshot today which includes it. Can you give it a try
>> >> >>> and see if everything works?
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Hans
>> >> >>>
>> >> >>> On Thu, Jan 5, 2017 at 10:46 AM, Zachary Turner
>> >> >>> 
>> >> >>> wrote:
>> >> >>> > I will commit it, in the meantime can you request commit access
>> >> >>> > so
>> >> >>> > that
>> >> >>> > any
>> >> >>> > future patches you can commit?
>> >> >>> >
>> >> >>> > On Wed, Jan 4, 2017 at 1:54 PM Vadim Chugunov 
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Thanks!
>> >> >>> >>
>> >> >>> >> Would anyone be so kind to commit that?
>> >> >>> >>
>> >> >>> >> On Wed, Jan 4, 2017 at 11:47 AM, Zachary Turner
>> >> >>> >> 
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> Sorry, a combination of national holidays and extended
>> >> >>> >>> vacations
>> >> >>> >>> happened
>> >> >>> >>> and this fell off my radar.  lgtm
>> >> >>> >>>
>> >> >>> >>> On Wed, Jan 4, 2017 at 11:46 AM Vadim Chugunov
>> >> >>> >>> 
>> >> >>> >>> wrote:
>> >> >>> 
>> >> >>>  Zachary,
>> >> >>>  Can you please take a look at that change?
>> >> >>>  (https://reviews.llvm.org/D27476)
>> >> >>> 
>> >> >>>  It'll be sad if another snapshot build gets published with
>> >> >>>  broken
>> >> >>>  lldb.
>> >> >>>  :(
>> >> >>> 
>> >> >>> 
>> >> >>>  On Tue, Dec 6, 2016 at 11:54 AM, Vadim Chugunov
>> >> >>>  
>> >> >>>  wrote:
>> >> >>> >
>> >> >>> > This seems to work: https://reviews.llvm.org/D27476
>> >> >>> >
>> >> >>> > On Mon, Dec 5, 2016 at 12:04 PM, Hans Wennborg
>> >> >>> > 
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> The only thing needed to build the installer should be
>> >> >>> >> having
>> >> >>> >> NSIS
>> >> >>> >> installed and building the "package" target generated by
>> >> >>> >> CMake.
>> >> >>> >> The
>> >> >>> >> other prerequisites are mostly for building the visual
>> >> >>> >> studio
>> >> >>> >> clang-format plugin.
>> >> >>> >>
>> >> >>> >> Having said that, you don't even have to build the installer
>> >> >>> >> to
>> >> >>> >> see
>> >> >>> >> what goes in it. Just building the "install" target
>> >> >>> >> generated
>> >> >>> >> by
>> >> >>> >> CMake
>> >> >>> >> will install the same set of files.
>> >> >>> >>
>> >> >>> >> I'm not sure how LLDB's cmake files are organized, but in
>> >> >>> >> the
>> >> >>> >> end
>> >> >>> >> what's required is invoking the install() command:
>> >> >>> >> https://cmake.org/cmake/help/v3.0/command/install.html  In
>> >> >>> >> LLVM,
>> >> >>> >> this
>> >> >>> >> is done automatically by macros such as add_llvm_executale,
>> >> >>> >> etc.
>> >> >>> >>
>> >> >>> >> On Mon, Dec 5, 2016 at 11:56 AM, Vadim Chugunov
>> >> >>> >> 
>> >> >>> >> wrote:
>> >> >>> >> > Hi Hans,
>> >> >>> >> >
>> >> >>> >> > I'd love to help, but I don't have half the tools that
>> >> >>> >> > build_llvm_package.bat requires instal

[lldb-dev] [4.0.0 Release] The branch is here, the release process starts

[Hans Wennborg via lldb-dev]

Dear everyone,

It has begun: the release branch was recently created from trunk at
r291814 and the trunk version was subsequently incremented to 5.0.0
(as per the new versioning scheme [1]).

Release blockers are tracked by http://llvm.org/PR31622 Please mark
any bugs, old or new, that you think need to be fixed before the
release as blocking that.

Please help me out in staying on top of the release by cc'ing me on
any bugs, commits, or other issues you think may be relevant. If I'm
not cc'd on it, there's a large chance I'll miss it. I'm on IRC too,
but email is more reliable.

If you know of any committs that occurred close to the branch that
need to be reverted or merged, please let me know.

To get a change committed to the branch, first commit to trunk as
usual, and then reply to the commit message on the mailing list with
myself and the code owner cc'd, asking for the change to be merged to
the branch. Alternatively, make the request by filing a bug blocking
PR31622.

Release notes should be committed directly to the branch. If you know
of any significant change made since the last release, it should get
mentioned in the notes.

What's next? Once the branch is in good shape, hopefully within a few
days, a first release candidate will be made available for testing.
The schedule for the release is under "Upcoming Releases" on
http://llvm.org.

Thanks,
Hans


 [1] http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [4.0.0 Release] The branch is here, the release process starts

[Hans Wennborg via lldb-dev]

It's there for me now:

$ git fetch origin
remote: Counting objects: 811, done.
remote: Compressing objects: 100% (561/561), done.
remote: Total 562 (delta 462), reused 2 (delta 0)
Receiving objects: 100% (562/562), 927.00 KiB | 1.29 MiB/s, done.
Resolving deltas: 100% (462/462), completed with 240 local objects.
From http://llvm.org/git/llvm
   233ecbde652..16c5e12d3a5  master -> origin/master
 * [new branch]  release_40 -> origin/release_40


On Fri, Jan 13, 2017 at 5:49 AM, Nicolai Hähnle  wrote:
> I don't see the release branch in the Git mirror at
> http://llvm.org/git/llvm.git yet. Is that going to appear soon?
>
> Thanks,
> Nicolai
>
>
> On 13.01.2017 00:34, Hans Wennborg via llvm-dev wrote:
>>
>> Dear everyone,
>>
>> It has begun: the release branch was recently created from trunk at
>> r291814 and the trunk version was subsequently incremented to 5.0.0
>> (as per the new versioning scheme [1]).
>>
>> Release blockers are tracked by http://llvm.org/PR31622 Please mark
>> any bugs, old or new, that you think need to be fixed before the
>> release as blocking that.
>>
>> Please help me out in staying on top of the release by cc'ing me on
>> any bugs, commits, or other issues you think may be relevant. If I'm
>> not cc'd on it, there's a large chance I'll miss it. I'm on IRC too,
>> but email is more reliable.
>>
>> If you know of any committs that occurred close to the branch that
>> need to be reverted or merged, please let me know.
>>
>> To get a change committed to the branch, first commit to trunk as
>> usual, and then reply to the commit message on the mailing list with
>> myself and the code owner cc'd, asking for the change to be merged to
>> the branch. Alternatively, make the request by filing a bug blocking
>> PR31622.
>>
>> Release notes should be committed directly to the branch. If you know
>> of any significant change made since the last release, it should get
>> mentioned in the notes.
>>
>> What's next? Once the branch is in good shape, hopefully within a few
>> days, a first release candidate will be made available for testing.
>> The schedule for the release is under "Upcoming Releases" on
>> http://llvm.org.
>>
>> Thanks,
>> Hans
>>
>>
>>  [1] http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-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] [4.0.0 Release] The branch is here, the release process starts

[Hans Wennborg via lldb-dev]

Oh wait, the branch on the git mirror doesn't look right!

Anton, can you take a look? The first commit on the branch for llvm is:


r291843 | hans | 2017-01-12 14:12:41 -0800 (Thu, 12 Jan 2017) | 1 line

Drop 'svn' suffix from version.


It should be similar for cfe and the others.

The current git mirror branch for llvm seems to only have one commit,
and that's one I just made:

$ git log --oneline origin/release_40
817cc1a7301 Merging r291863:

r291863 | chapuni | 2017-01-12 16:17:15 -0800 (Thu, 12 Jan 2017) | 1
line

Note that it doesn't have any parent!

On Fri, Jan 13, 2017 at 9:23 AM, Hans Wennborg  wrote:
> It's there for me now:
>
> $ git fetch origin
> remote: Counting objects: 811, done.
> remote: Compressing objects: 100% (561/561), done.
> remote: Total 562 (delta 462), reused 2 (delta 0)
> Receiving objects: 100% (562/562), 927.00 KiB | 1.29 MiB/s, done.
> Resolving deltas: 100% (462/462), completed with 240 local objects.
> From http://llvm.org/git/llvm
>233ecbde652..16c5e12d3a5  master -> origin/master
>  * [new branch]  release_40 -> origin/release_40
>
>
> On Fri, Jan 13, 2017 at 5:49 AM, Nicolai Hähnle  wrote:
>> I don't see the release branch in the Git mirror at
>> http://llvm.org/git/llvm.git yet. Is that going to appear soon?
>>
>> Thanks,
>> Nicolai
>>
>>
>> On 13.01.2017 00:34, Hans Wennborg via llvm-dev wrote:
>>>
>>> Dear everyone,
>>>
>>> It has begun: the release branch was recently created from trunk at
>>> r291814 and the trunk version was subsequently incremented to 5.0.0
>>> (as per the new versioning scheme [1]).
>>>
>>> Release blockers are tracked by http://llvm.org/PR31622 Please mark
>>> any bugs, old or new, that you think need to be fixed before the
>>> release as blocking that.
>>>
>>> Please help me out in staying on top of the release by cc'ing me on
>>> any bugs, commits, or other issues you think may be relevant. If I'm
>>> not cc'd on it, there's a large chance I'll miss it. I'm on IRC too,
>>> but email is more reliable.
>>>
>>> If you know of any committs that occurred close to the branch that
>>> need to be reverted or merged, please let me know.
>>>
>>> To get a change committed to the branch, first commit to trunk as
>>> usual, and then reply to the commit message on the mailing list with
>>> myself and the code owner cc'd, asking for the change to be merged to
>>> the branch. Alternatively, make the request by filing a bug blocking
>>> PR31622.
>>>
>>> Release notes should be committed directly to the branch. If you know
>>> of any significant change made since the last release, it should get
>>> mentioned in the notes.
>>>
>>> What's next? Once the branch is in good shape, hopefully within a few
>>> days, a first release candidate will be made available for testing.
>>> The schedule for the release is under "Upcoming Releases" on
>>> http://llvm.org.
>>>
>>> Thanks,
>>> Hans
>>>
>>>
>>>  [1] http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html
>>> ___
>>> LLVM Developers mailing list
>>> llvm-...@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

Dear testers,

4.0.0-rc1 was just tagged from the branch, with r292377.

There are still open merge requests and bugs, but I'd like to get the
testing started to see what issues come up.

Please build, test, and upload binaries to the sftp. Let me know how
it goes. I'll upload source, docs, and your binaries to the web site
once their ready.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

The script lives in the llvm repo: utils/release/test-release.sh.
You'll probably want to invoke it as test-release.sh -release 4.0.0
-rc
1 -triple x86_64-apple-darwin

On Wed, Jan 18, 2017 at 10:26 AM, Mehdi Amini  wrote:
> Hi Hans,
>
> I can test it on macOS. Is there a doc to describe what to test? I remember 
> you pointed me to a script once…
> Anyone else involved in the release process on macOS?
>
> Thanks,
>
> —
> Mehdi
>
>
>
>
>> On Jan 18, 2017, at 7:45 AM, Hans Wennborg via llvm-dev 
>>  wrote:
>>
>> Dear testers,
>>
>> 4.0.0-rc1 was just tagged from the branch, with r292377.
>>
>> There are still open merge requests and bugs, but I'd like to get the
>> testing started to see what issues come up.
>>
>> Please build, test, and upload binaries to the sftp. Let me know how
>> it goes. I'll upload source, docs, and your binaries to the web site
>> once their ready.
>>
>> Thanks,
>> Hans
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-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] [4.0.0 Release] Relase Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

If you're using the svn repository you can just check out the
RELEASE_400/rc1 tag of the cfe module.

If you're using the git mirror, the last cfe commit on the release_40
branch before the tag is 3a631d565d.

Thanks,
Hans

On Wed, Jan 18, 2017 at 10:11 AM, Andrew Kelley  wrote:
> I'd like to test this, but I also need to test the corresponding libclang
> version at the same time. Which revision of cfe is 4.0.0-rc1?
>
> On Wed, Jan 18, 2017 at 10:45 AM, Hans Wennborg via llvm-dev
>  wrote:
>>
>> Dear testers,
>>
>> 4.0.0-rc1 was just tagged from the branch, with r292377.
>>
>> There are still open merge requests and bugs, but I'd like to get the
>> testing started to see what issues come up.
>>
>> Please build, test, and upload binaries to the sftp. Let me know how
>> it goes. I'll upload source, docs, and your binaries to the web site
>> once their ready.
>>
>> Thanks,
>> Hans
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

On Wed, Jan 18, 2017 at 4:43 PM, Mehdi Amini  wrote:
>
>> On Jan 18, 2017, at 7:45 AM, Hans Wennborg via cfe-dev 
>>  wrote:
>>
>> Dear testers,
>>
>> 4.0.0-rc1 was just tagged from the branch, with r292377.
>>
>> There are still open merge requests and bugs, but I'd like to get the
>> testing started to see what issues come up.
>>
>> Please build, test, and upload binaries to the sftp. Let me know how
>> it goes. I'll upload source, docs, and your binaries to the web site
>> once their ready.
>
> I built successfully, it the something specific you do for testing?

The script tests that bootstrapping and running all the lit tests work.

Some testers run the test-suite (which I'm not really familiar with
myself) and if they have other code bases they care about.

But running test-release.sh is what I'm asking for really.

> Am I expected to upload clang+llvm-4.0.0-rc1-x86_64-apple-darwin.tar.xz 
> somewhere? (I don’t what sftp you’re referring to above).

Yes. I've asked Anton to give you access.

>
> Pardon my ignorance, first time I participate in the release process :)

No problem at all, and thanks very much for doing this.

Cheers,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [4.0.0 Release] Relase Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

On Thu, Jan 19, 2017 at 12:12 AM, Dimitry Andric  wrote:
> On 18 Jan 2017, at 16:45, Hans Wennborg via Release-testers 
>  wrote:
>> Dear testers,
>>
>> 4.0.0-rc1 was just tagged from the branch, with r292377.
>>
>> There are still open merge requests and bugs, but I'd like to get the
>> testing started to see what issues come up.
>
> Unfortunately no builds for FreeBSD yet, as the Phase1 clang segfaults when 
> building AsmParser.cpp:
>
> [  1%] Building CXX object 
> lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o
> cd 
> /home/dim/llvm-4.0.0/rc1/Phase2/Release/llvmCore-4.0.0-rc1.obj/lib/MC/MCParser
>  && /home/dim/llvm-4.0
> .0/rc1/Phase1/Release/llvmCore-4.0.0-rc1.install/usr/local/bin/clang++   
> -DGTEST_HAS_RTTI=0 -D__STDC_CO
> NSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
> -I/home/dim/llvm-4.0.0/rc1/Phase2/Release/ll
> vmCore-4.0.0-rc1.obj/lib/MC/MCParser 
> -I/home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser -I/home/dim/ll
> vm-4.0.0/rc1/Phase2/Release/llvmCore-4.0.0-rc1.obj/include 
> -I/home/dim/llvm-4.0.0/rc1/llvm.src/include
> -I/usr/local/include  -fPIC -fvisibility-inlines-hidden -Wall -W 
> -Wno-unused-parameter -Wwrite-strings
> -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long 
> -Wcovered-switch-default -Wnon-virtua
> l-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -Werror=date-time 
> -std=c++11 -ffunction-sections -
> fdata-sections -O3 -DNDEBUG-fno-exceptions -fno-rtti -o 
> CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o
>  -c /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp
> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2043:25: 
> warning: variable 'CppHashLocL
> ineNo' is uninitialized when used here [-Wuninitialized]
> LastQueryLine = CppHashLocLineNo;
> ^~~~
> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2036:32: 
> note: initialize the variable
> 'CppHashLocLineNo' to silence this warning
>   unsigned CppHashLocLineNo;
>^
> = 0
> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2155:71: 
> warning: variable 'LineNo' is
> uninitialized when used here [-Wuninitialized]
>   SMDiagnostic NewDiag(*Diag.getSourceMgr(), Diag.getLoc(), Filename, LineNo,
>   ^~
> /home/dim/llvm-4.0.0/rc1/llvm.src/lib/MC/MCParser/AsmParser.cpp:2152:13: 
> note: initialize the variable
> 'LineNo' to silence this warning
>   int LineNo =
> ^
>  = 0
> clang-4.0: error: unable to execute command: Segmentation fault (core dumped)
> clang-4.0: error: clang frontend command failed due to signal (use -v to see 
> invocation)
> clang version 4.0.0 (tags/RELEASE_400/rc1)
> Target: i386-unknown-freebsd10.3
> Thread model: posix
> InstalledDir: 
> /home/dim/llvm-4.0.0/rc1/Phase1/Release/llvmCore-4.0.0-rc1.install/usr/local/bin
> clang-4.0: note: diagnostic msg: PLEASE submit a bug report to 
> http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, 
> and associated run script.
> clang-4.0: note: diagnostic msg:
> 
>
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> clang-4.0: note: diagnostic msg: /home/dim/tmp/AsmParser-c3ca7e.cpp
> clang-4.0: note: diagnostic msg: /home/dim/tmp/AsmParser-c3ca7e.sh
> clang-4.0: note: diagnostic msg:
>
> 
> gmake[2]: *** [lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/build.make:87: 
> lib/MC/MCParser/CMakeFiles/LLVMMCParser.dir/AsmParser.cpp.o] Error 254
>
> I thought this might be because r292133 was not merged yet, but I was wrong 
> about that, it *is* merged.
>
> So I will have to investigate why it crashes here.

Is this PR31692 that you filed today?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

Hi David,

Please file a bug about the lld issue on http://llvm.org/bugs and mark
it blocking PR31622.

I've merged the clang-tools-extra commit you pointed to in r292834.

Thanks,
Hans

On Fri, Jan 20, 2017 at 10:56 AM, David Abdurachmanov
 wrote:
> Hi,
>
> While building a full stack LLVM/Clang/lld/compiler-rt/clang-tools-extra/
> openmp/etc in a single RPM I hit a couple of issues.
>
> (1)
>
> lld was broken as liblldCOFF.so, liblldDriver.so and liblldELF.so are
> no more installed, but lld binary depends on them.
>
> At first look probably caused by this: https://reviews.llvm.org/D28397
>
> (2)
>
> https://github.com/llvm-mirror/clang-tools-extra/tree/release_40
> Needs 1a15ce4331f4692e7931f07cb3eaf49355ce2c1e from master branch to compile.
>
> Otherwise the builds fails with undefined reference to pthread_create at link 
> time.
>
> Cheers,
> david
>
>> On 20 Jan 2017, at 11:45, Tobias Grosser via cfe-dev 
>>  wrote:
>>
>> Very cool initiative! Thank you!
>>
>> On Fri, Jan 20, 2017, at 10:59 AM, Mehdi Amini via cfe-dev wrote:
>>> Hi,
>>>
>>> FYI, I added a Green dragon job to build and test (stage 1 only right
>>> now) the release branch:
>>> http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA-release-4/
>>> 
>>>
>>> —
>>> Mehdi
>>>
 On Jan 18, 2017, at 7:45 AM, Hans Wennborg via llvm-dev 
  wrote:

 Dear testers,

 4.0.0-rc1 was just tagged from the branch, with r292377.

 There are still open merge requests and bugs, but I'd like to get the
 testing started to see what issues come up.

 Please build, test, and upload binaries to the sftp. Let me know how
 it goes. I'll upload source, docs, and your binaries to the web site
 once their ready.

 Thanks,
 Hans
 ___
 LLVM Developers mailing list
 llvm-...@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>> ___
>>> cfe-dev mailing list
>>> cfe-...@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> ___
>> 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] [4.0.0 Release] Relase Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

On Fri, Jan 20, 2017 at 2:35 PM, Bernhard Rosenkränzer
 wrote:
> Hi,
> updated OpenMandriva packaging. Looks good, so far passes testing on all 4
> supported arches (x86_32, x86_64, armv7hnl, aarch64) after fixing one build
> issue in clang-tools-extra:
>
> FAILED: lib64/libclangIncludeFixerPlugin.so.4.0.0
> : && /usr/bin/clang++  -fPIC -Os  -pipe -Wformat -Werror=format-security
> -D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4  -fPIC -fPIC
> -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
> -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long
> -Wcovered-switch-default -Wnon-virtual-dt
> or -Wdelete-non-virtual-dtor -Wstring-conversion -Werror=date-time
> -std=c++1y -fcolor-diagnostics -ffunction-sections -fdata-sections
> -fno-common -Woverloaded-virtual -Wno-nested-anon-types -Os  -pipe -Wformat
> -Werror=format-security -D_FORTIFY_SOURCE=2 -fstack-protector
> --param=ssp-buffer-size=4  -fPIC  -L/home/bero/abf/llvm/BUIL
> D/llvm-4.0.0.src/build/lib64 -Wl,-z,defs   -Wl,-O3 -Wl,--gc-sections -shared
> -Wl,-soname,libclangIncludeFixerPlugin.so.4.0 -o
> lib64/libclangIncludeFixerPlugin.so.4.0.0
> tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o
> lib64/libclangAST.so.4.0.0 lib64/libclangBasic.so.4.0.
> 0 lib64/libclangFrontend.so.4.0.0 lib64/libclangIncludeFixer.so.4.0.0
> lib64/libclangParse.so.4.0.0 lib64/libclangSema.so.4.0.0
> lib64/libclangTooling.so.4.0.0 lib64/libLLVMSupport.so.4.0.0 && :
> tools/clang/tools/extra/include-fixer/plugin/CMakeFiles/clangIncludeFixerPlugin.dir/IncludeFixerPlugin.cpp.o:/home/bero/abf/llvm/BUILD/llvm-4.0.0.src/tools/clang/tools/extra/include-fixer/plugin/IncludeFixerPlugin.cpp:function
> std::thread::thread  std::default_delete > ()> ()>,
> std::unique_ptr std::default_delete >
>>::_Async_state_impl(std::_Bind_simple std::default_delet
> e > ()>
> ()>&&)::{lambda()#1}>(std::__future_base::_Async_state_impl std::default_delete > ()> ()>,
> std::unique_ptr std::default_delete clude_fixer::SymbolIndex> >
>>::_Async_state_impl(std::_Bind_simple std::default_delete > ()>
> ()>&&)::{lambda()#1}&&): error: undefined reference to 'pthread_create'
> clang-4.0: error: linker command failed with exit code 1 (use -v to see
> invocation)
> ninja: build stopped: subcommand failed.
>
> Patch for this issue is attached (but will likely break Windows builds -
> probably needs a platform check added).

Benjamin landed that fix in r291892 which was just merged, so
hopefully that's all good now.

Thanks,
Hans


> On 18 January 2017 at 16:45, Hans Wennborg via Release-testers
>  wrote:
>>
>> Dear testers,
>>
>> 4.0.0-rc1 was just tagged from the branch, with r292377.
>>
>> There are still open merge requests and bugs, but I'd like to get the
>> testing started to see what issues come up.
>>
>> Please build, test, and upload binaries to the sftp. Let me know how
>> it goes. I'll upload source, docs, and your binaries to the web site
>> once their ready.
>>
>> Thanks,
>> Hans
>> ___
>> 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

[lldb-dev] [4.0.0 Release] Release Candidate 1 source and binaries available

[Hans Wennborg via lldb-dev]

Source, binaries and docs for LLVM-4.0.0-rc1 are now available at
http://www.llvm.org/pre-releases/4.0.0/#rc1

Please try it out, run tests, build your favourite projects and file
bugs about anything that doesn't work and needs to be fixed before the
release, marking them as blockers of http://llvm.org/pr31622.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [cfe-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

On Tue, Jan 24, 2017 at 10:29 AM, Simon Dardis  wrote:
> Looks ok for native MIPS, I have two failures on debian8:
>
> Failing Tests (2):
> XRay-x86_64-linux :: TestCases/Linux/argv0-log-file-name.cc
> XRay-x86_64-linux :: TestCases/Linux/fixedsize-logging.cc
>
> I'll investigate these failures. Otherwise looks ok.

Thanks! Can you file a bug for those failures with the output if possible?

> I've uploaded the binaries.
>
> 9d5a389c20eb5b3071e6a0504b7cf87d  clang+llvm-4.0.0-rc1-mipsel-linux-gnu.tar.xz
> 655f566cd16740aaa542d94bcea18490  clang+llvm-4.0.0-rc1-mips-linux-gnu.tar.xz
> c505d9e2f95143492e134b268479246b  
> clang+llvm-4.0.0-rc1-x86_64-linux-gnu-debian8.tar.xz

I don't see the debian8 file on the sftp. Did you forget to upload it?

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [cfe-dev] [4.0.0 Release] Relase Candidate 1 has been tagged

[Hans Wennborg via lldb-dev]

Thanks! I've added the binaries to the pre-release web page.

Cheers,
Hans

On Wed, Jan 25, 2017 at 12:57 PM, Simon Dardis  wrote:
> Test failures filed under PR/31756, noting the cause. I've posted on PR/31622 
> asking whether we should consider
> this a release blocker.
>
> Uploaded clang+llvm-4.0.0-rc1-x86_64-linux-gnu-debian8.tar.xz, I must have 
> made some mistake when uploading
> it, corrected now.
>
> Thanks,
> Simon
> 
> From: hwennb...@google.com [hwennb...@google.com] on behalf of Hans Wennborg 
> [h...@chromium.org]
> Sent: 25 January 2017 17:32
> To: Simon Dardis
> Cc: llvm-...@lists.llvm.org; release-test...@lists.llvm.org; 
> cfe-...@lists.llvm.org; openmp-...@lists.llvm.org; lldb-dev@lists.llvm.org
> Subject: Re: [Release-testers] [cfe-dev] [4.0.0 Release] Relase Candidate 1 
> has been tagged
>
> On Tue, Jan 24, 2017 at 10:29 AM, Simon Dardis  
> wrote:
>> Looks ok for native MIPS, I have two failures on debian8:
>>
>> Failing Tests (2):
>> XRay-x86_64-linux :: TestCases/Linux/argv0-log-file-name.cc
>> XRay-x86_64-linux :: TestCases/Linux/fixedsize-logging.cc
>>
>> I'll investigate these failures. Otherwise looks ok.
>
> Thanks! Can you file a bug for those failures with the output if possible?
>
>> I've uploaded the binaries.
>>
>> 9d5a389c20eb5b3071e6a0504b7cf87d  
>> clang+llvm-4.0.0-rc1-mipsel-linux-gnu.tar.xz
>> 655f566cd16740aaa542d94bcea18490  clang+llvm-4.0.0-rc1-mips-linux-gnu.tar.xz
>> c505d9e2f95143492e134b268479246b  
>> clang+llvm-4.0.0-rc1-x86_64-linux-gnu-debian8.tar.xz
>
> I don't see the debian8 file on the sftp. Did you forget to upload it?
>
> Thanks,
> Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev