[3.7 Release] RC1 has been tagged, Testing Phase I begins

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
65 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[3.7 Release] RC1 has been tagged, Testing Phase I begins

Hans Wennborg-2
Dear testers,

3.7.0-rc1 was just tagged; please start your testing engines :-)

Upload binaries to the sftp and report your results to this thread.

I'm sorry for the delay between branching and tagging. The changes to
the release script took a little longer than I hoped.

Thanks for helping with the release, and do let me know of any issues,
questions, etc.

The tracking bug for release blockers is PR24126.

Cheers,
Hans
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Dimitry Andric
On 17 Jul 2015, at 00:31, Hans Wennborg <[hidden email]> wrote:

>
> Dear testers,
>
> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>
> Upload binaries to the sftp and report your results to this thread.
>
> I'm sorry for the delay between branching and tagging. The changes to
> the release script took a little longer than I hoped.
>
> Thanks for helping with the release, and do let me know of any issues,
> questions, etc.
>
> The tracking bug for release blockers is PR24126.
Is it OK to do an autoconf build?  The CMake build tries to build various components which do not yet work on FreeBSD, e.g. libcxxabi does not compile at all, libcompiler-rt has a bunch of test failures, etc.  Alternatively, can I disable these components in the CMake build locally?

-Dimitry


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Jack Howarth-2
In reply to this post by Hans Wennborg-2
Hans,
      Do we intend to leave -fopenmp defaulted to the no-op libgomp
support for 3.7.0 or do the sensible thing by applying...

Index: CMakeLists.txt
===================================================================
--- CMakeLists.txt (revision 242425)
+++ CMakeLists.txt (working copy)
@@ -182,7 +182,7 @@ set(GCC_INSTALL_PREFIX "" CACHE PATH "Di
 set(DEFAULT_SYSROOT "" CACHE PATH
   "Default <path> to all compiler invocations for --sysroot=<path>." )

-set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING
+set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
   "Default OpenMP runtime used by -fopenmp.")

 set(CLANG_VENDOR "" CACHE STRING

so that the new llvm openmp library (which passes a three stage
bootstrap as part of an
in-tree build of llvm/cfe/compiler-rt/polly/libc++/openmp on
x86_64-apple-darwin).
                   Jack

On Thu, Jul 16, 2015 at 6:31 PM, Hans Wennborg <[hidden email]> wrote:

> Dear testers,
>
> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>
> Upload binaries to the sftp and report your results to this thread.
>
> I'm sorry for the delay between branching and tagging. The changes to
> the release script took a little longer than I hoped.
>
> Thanks for helping with the release, and do let me know of any issues,
> questions, etc.
>
> The tracking bug for release blockers is PR24126.
>
> Cheers,
> Hans
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Hans Wennborg-2
In reply to this post by Dimitry Andric
On Thu, Jul 16, 2015 at 3:47 PM, Dimitry Andric <[hidden email]> wrote:

> On 17 Jul 2015, at 00:31, Hans Wennborg <[hidden email]> wrote:
>>
>> Dear testers,
>>
>> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>>
>> Upload binaries to the sftp and report your results to this thread.
>>
>> I'm sorry for the delay between branching and tagging. The changes to
>> the release script took a little longer than I hoped.
>>
>> Thanks for helping with the release, and do let me know of any issues,
>> questions, etc.
>>
>> The tracking bug for release blockers is PR24126.
>
> Is it OK to do an autoconf build?  The CMake build tries to build various components which do not yet work on FreeBSD, e.g. libcxxabi does not compile at all, libcompiler-rt has a bunch of test failures, etc.  Alternatively, can I disable these components in the CMake build locally?

Yes, go ahead and use the autoconf build.

Can you send a patch to test-release.sh that makes this default for
FreeBSD? It's already the default for Darwin.

Thanks,
Hans

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Hans Wennborg-2
In reply to this post by Jack Howarth-2
Hi Jack,

On Thu, Jul 16, 2015 at 4:03 PM, Jack Howarth
<[hidden email]> wrote:

> Hans,
>       Do we intend to leave -fopenmp defaulted to the no-op libgomp
> support for 3.7.0 or do the sensible thing by applying...
>
> Index: CMakeLists.txt
> ===================================================================
> --- CMakeLists.txt (revision 242425)
> +++ CMakeLists.txt (working copy)
> @@ -182,7 +182,7 @@ set(GCC_INSTALL_PREFIX "" CACHE PATH "Di
>  set(DEFAULT_SYSROOT "" CACHE PATH
>    "Default <path> to all compiler invocations for --sysroot=<path>." )
>
> -set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING
> +set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
>    "Default OpenMP runtime used by -fopenmp.")
>
>  set(CLANG_VENDOR "" CACHE STRING
>
> so that the new llvm openmp library (which passes a three stage
> bootstrap as part of an
> in-tree build of llvm/cfe/compiler-rt/polly/libc++/openmp on
> x86_64-apple-darwin).

I'm not fully aware of the implications of this, but if we do want to
change it, it needs to be done on trunk first.

If you get it through review and committed to trunk, I'm open to merging it.

I assume utils/release/test-release.sh would also need an update so
the library gets built?

Thanks,
Hans
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Nikola Smiljanic
CMake Error at projects/compiler-rt/cmake/config-ix.cmake:125 (message): Cannot compile for i686

CMakeError.log attached, seems like #include checks are failing? This is x86 openSUSE.

On Fri, Jul 17, 2015 at 9:14 AM, Hans Wennborg <[hidden email]> wrote:
Hi Jack,

On Thu, Jul 16, 2015 at 4:03 PM, Jack Howarth
<[hidden email]> wrote:
> Hans,
>       Do we intend to leave -fopenmp defaulted to the no-op libgomp
> support for 3.7.0 or do the sensible thing by applying...
>
> Index: CMakeLists.txt
> ===================================================================
> --- CMakeLists.txt (revision 242425)
> +++ CMakeLists.txt (working copy)
> @@ -182,7 +182,7 @@ set(GCC_INSTALL_PREFIX "" CACHE PATH "Di
>  set(DEFAULT_SYSROOT "" CACHE PATH
>    "Default <path> to all compiler invocations for --sysroot=<path>." )
>
> -set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING
> +set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
>    "Default OpenMP runtime used by -fopenmp.")
>
>  set(CLANG_VENDOR "" CACHE STRING
>
> so that the new llvm openmp library (which passes a three stage
> bootstrap as part of an
> in-tree build of llvm/cfe/compiler-rt/polly/libc++/openmp on
> x86_64-apple-darwin).

I'm not fully aware of the implications of this, but if we do want to
change it, it needs to be done on trunk first.

If you get it through review and committed to trunk, I'm open to merging it.

I assume utils/release/test-release.sh would also need an update so
the library gets built?

Thanks,
Hans


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

CMakeError.log.zip (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Renato Golin-2
In reply to this post by Hans Wennborg-2
Hi Hans,

We're missing libunwind from the list of projects in 3.7.

The current way libcxxabi builds depends on libunwin (looking for
libunwind.h), so we need to tag libunwind, check it out in the script
and build it together.

For now, I'll disable libcxx from my build, but it would be good to
have it on later, so we can test it with the rest, too.

cheers,
--renato

On 16 July 2015 at 23:31, Hans Wennborg <[hidden email]> wrote:

> Dear testers,
>
> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>
> Upload binaries to the sftp and report your results to this thread.
>
> I'm sorry for the delay between branching and tagging. The changes to
> the release script took a little longer than I hoped.
>
> Thanks for helping with the release, and do let me know of any issues,
> questions, etc.
>
> The tracking bug for release blockers is PR24126.
>
> Cheers,
> Hans
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Jack Howarth-2
In reply to this post by Hans Wennborg-2
Hans,
      This change is required because Chandler reverted the OpenMP
developers original commit that enabled clang to default to the new
OpenMP with...

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150518/129487.html

The major complaints with the cmake support for OpenMP have been addressed in...

http://lists.cs.uiuc.edu/pipermail/openmp-commits/2015-July/000441.html
http://lists.cs.uiuc.edu/pipermail/openmp-commits/2015-July/000442.html

as well as in prior commits which addressed the cmake variable naming
convention issues.
              Otherwise, the release notes for 3.7.0 will have to
explain why we don't trust our own fully functional OpenMP 3.1 support
to the point that we choose to default to non-functional libgomp
support. Note that the -fopenmp currently implies -fopenmp=libgomp
which doesn't generate any code for OpenMP support is thus simple
serial execution.
          Jack

On Thu, Jul 16, 2015 at 7:14 PM, Hans Wennborg <[hidden email]> wrote:

> Hi Jack,
>
> On Thu, Jul 16, 2015 at 4:03 PM, Jack Howarth
> <[hidden email]> wrote:
>> Hans,
>>       Do we intend to leave -fopenmp defaulted to the no-op libgomp
>> support for 3.7.0 or do the sensible thing by applying...
>>
>> Index: CMakeLists.txt
>> ===================================================================
>> --- CMakeLists.txt (revision 242425)
>> +++ CMakeLists.txt (working copy)
>> @@ -182,7 +182,7 @@ set(GCC_INSTALL_PREFIX "" CACHE PATH "Di
>>  set(DEFAULT_SYSROOT "" CACHE PATH
>>    "Default <path> to all compiler invocations for --sysroot=<path>." )
>>
>> -set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING
>> +set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
>>    "Default OpenMP runtime used by -fopenmp.")
>>
>>  set(CLANG_VENDOR "" CACHE STRING
>>
>> so that the new llvm openmp library (which passes a three stage
>> bootstrap as part of an
>> in-tree build of llvm/cfe/compiler-rt/polly/libc++/openmp on
>> x86_64-apple-darwin).
>
> I'm not fully aware of the implications of this, but if we do want to
> change it, it needs to be done on trunk first.
>
> If you get it through review and committed to trunk, I'm open to merging it.
>
> I assume utils/release/test-release.sh would also need an update so
> the library gets built?
>
> Thanks,
> Hans
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Hans Wennborg-2
In reply to this post by Renato Golin-2
Hi Renato,

On Fri, Jul 17, 2015 at 6:42 AM, Renato Golin <[hidden email]> wrote:
> We're missing libunwind from the list of projects in 3.7.
>
> The current way libcxxabi builds depends on libunwin (looking for
> libunwind.h), so we need to tag libunwind, check it out in the script
> and build it together.
>
> For now, I'll disable libcxx from my build, but it would be good to
> have it on later, so we can test it with the rest, too.

I've created the branch and rc1 tag for libunwind, and included it in
the scripts in r242543. Let me know how it works out.

Thanks,
Hans


> On 16 July 2015 at 23:31, Hans Wennborg <[hidden email]> wrote:
>> Dear testers,
>>
>> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>>
>> Upload binaries to the sftp and report your results to this thread.
>>
>> I'm sorry for the delay between branching and tagging. The changes to
>> the release script took a little longer than I hoped.
>>
>> Thanks for helping with the release, and do let me know of any issues,
>> questions, etc.
>>
>> The tracking bug for release blockers is PR24126.
>>
>> Cheers,
>> Hans
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Hans Wennborg-2
In reply to this post by Jack Howarth-2
Hi Jack,

On Fri, Jul 17, 2015 at 6:46 AM, Jack Howarth
<[hidden email]> wrote:

> Hans,
>       This change is required because Chandler reverted the OpenMP
> developers original commit that enabled clang to default to the new
> OpenMP with...
>
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150518/129487.html
>
> The major complaints with the cmake support for OpenMP have been addressed in...
>
> http://lists.cs.uiuc.edu/pipermail/openmp-commits/2015-July/000441.html
> http://lists.cs.uiuc.edu/pipermail/openmp-commits/2015-July/000442.html
>
> as well as in prior commits which addressed the cmake variable naming
> convention issues.

Thank you for the links.

It's not me you need to convince though. As I said before, the change
would have to be committed to trunk first, and then I'm open to
consider merging it.

Thanks,
Hans

> On Thu, Jul 16, 2015 at 7:14 PM, Hans Wennborg <[hidden email]> wrote:
>> Hi Jack,
>>
>> On Thu, Jul 16, 2015 at 4:03 PM, Jack Howarth
>> <[hidden email]> wrote:
>>> Hans,
>>>       Do we intend to leave -fopenmp defaulted to the no-op libgomp
>>> support for 3.7.0 or do the sensible thing by applying...
>>>
>>> Index: CMakeLists.txt
>>> ===================================================================
>>> --- CMakeLists.txt (revision 242425)
>>> +++ CMakeLists.txt (working copy)
>>> @@ -182,7 +182,7 @@ set(GCC_INSTALL_PREFIX "" CACHE PATH "Di
>>>  set(DEFAULT_SYSROOT "" CACHE PATH
>>>    "Default <path> to all compiler invocations for --sysroot=<path>." )
>>>
>>> -set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING
>>> +set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
>>>    "Default OpenMP runtime used by -fopenmp.")
>>>
>>>  set(CLANG_VENDOR "" CACHE STRING
>>>
>>> so that the new llvm openmp library (which passes a three stage
>>> bootstrap as part of an
>>> in-tree build of llvm/cfe/compiler-rt/polly/libc++/openmp on
>>> x86_64-apple-darwin).
>>
>> I'm not fully aware of the implications of this, but if we do want to
>> change it, it needs to be done on trunk first.
>>
>> If you get it through review and committed to trunk, I'm open to merging it.
>>
>> I assume utils/release/test-release.sh would also need an update so
>> the library gets built?
>>
>> Thanks,
>> Hans
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Hans Wennborg-2
In reply to this post by Nikola Smiljanic
Seems on OpenSUSE x86, it's called i586, not i686 :-(

+Alexey: do you think we can handle this in the compiler-rt cmake
files somehow? Maybe try targeting both i686 and i586 unless that
would break something else?

On Fri, Jul 17, 2015 at 1:31 AM, Nikola Smiljanic <[hidden email]> wrote:

> CMake Error at projects/compiler-rt/cmake/config-ix.cmake:125 (message):
> Cannot compile for i686
>
> CMakeError.log attached, seems like #include checks are failing? This is x86
> openSUSE.
>
> On Fri, Jul 17, 2015 at 9:14 AM, Hans Wennborg <[hidden email]> wrote:
>>
>> Hi Jack,
>>
>> On Thu, Jul 16, 2015 at 4:03 PM, Jack Howarth
>> <[hidden email]> wrote:
>> > Hans,
>> >       Do we intend to leave -fopenmp defaulted to the no-op libgomp
>> > support for 3.7.0 or do the sensible thing by applying...
>> >
>> > Index: CMakeLists.txt
>> > ===================================================================
>> > --- CMakeLists.txt (revision 242425)
>> > +++ CMakeLists.txt (working copy)
>> > @@ -182,7 +182,7 @@ set(GCC_INSTALL_PREFIX "" CACHE PATH "Di
>> >  set(DEFAULT_SYSROOT "" CACHE PATH
>> >    "Default <path> to all compiler invocations for --sysroot=<path>." )
>> >
>> > -set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING
>> > +set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING
>> >    "Default OpenMP runtime used by -fopenmp.")
>> >
>> >  set(CLANG_VENDOR "" CACHE STRING
>> >
>> > so that the new llvm openmp library (which passes a three stage
>> > bootstrap as part of an
>> > in-tree build of llvm/cfe/compiler-rt/polly/libc++/openmp on
>> > x86_64-apple-darwin).
>>
>> I'm not fully aware of the implications of this, but if we do want to
>> change it, it needs to be done on trunk first.
>>
>> If you get it through review and committed to trunk, I'm open to merging
>> it.
>>
>> I assume utils/release/test-release.sh would also need an update so
>> the library gets built?
>>
>> Thanks,
>> Hans
>
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Renato Golin-2
In reply to this post by Hans Wennborg-2
On 17 July 2015 at 17:53, Hans Wennborg <[hidden email]> wrote:
> I've created the branch and rc1 tag for libunwind, and included it in
> the scripts in r242543. Let me know how it works out.

Thanks! It solved the CMake issue, but now it doesn't build. Since I
had problems building libcxx on ARM directly before, I won't release
them now. Just Clang+tools and Compiler RT.

Still, removing the libraries from the list of projects (and
commenting out the hardcoded symlinks), I can build all the way to
Phase3, but some of the ASAN tests fail (not sure why) and the tar
ball isn't created.

I'll investigate the ASAN issues, but it would be good to create the
binary package anyway, so at least I can upload it to the website and
other people test their stuff while I figure out the problems in the
tests.

Finally, for some reason, the install directory is
...install/usr/local/... which is odd.

I'll send a patch with some changes to the test-release.sh script.

cheers,
--renato
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Hans Wennborg-2
On Fri, Jul 17, 2015 at 12:19 PM, Renato Golin <[hidden email]> wrote:
> On 17 July 2015 at 17:53, Hans Wennborg <[hidden email]> wrote:
>> I've created the branch and rc1 tag for libunwind, and included it in
>> the scripts in r242543. Let me know how it works out.
>
> Thanks! It solved the CMake issue, but now it doesn't build. Since I
> had problems building libcxx on ARM directly before, I won't release
> them now. Just Clang+tools and Compiler RT.

Sounds good to me.

>
> Still, removing the libraries from the list of projects (and
> commenting out the hardcoded symlinks), I can build all the way to
> Phase3, but some of the ASAN tests fail (not sure why) and the tar
> ball isn't created.
>
> I'll investigate the ASAN issues, but it would be good to create the
> binary package anyway, so at least I can upload it to the website and
> other people test their stuff while I figure out the problems in the
> tests.

I thought we ran the tests with "make -k", so I'd expect the tarball
to be created anyway. Hmm...

>
> Finally, for some reason, the install directory is
> ...install/usr/local/... which is odd.

Oops, that's from r242187. I think the install directory is fine, but
it shouldn't become part of the tarball.

> I'll send a patch with some changes to the test-release.sh script.

Thanks! Are you including a fix for not including "/usr/local" in the
tarball? Otherwise I'll do that.

Cheers,
Hans
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Renato Golin-2
On 17 July 2015 at 20:36, Hans Wennborg <[hidden email]> wrote:
> Thanks! Are you including a fix for not including "/usr/local" in the
> tarball? Otherwise I'll do that.

I was going to send two patches, but feel free to get that one out of
the way, since you know where to fix it.

cheers,
--renato
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Renato Golin-2
In reply to this post by Hans Wennborg-2
On 16 July 2015 at 23:31, Hans Wennborg <[hidden email]> wrote:
> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>
> Upload binaries to the sftp and report your results to this thread.

ARMv7 with Compiler-RT up. There were unexpected passes on the
sanitizer, but that's ok.

I'm running tests and benchmarks now, but people can already try it
out if they want.

AArch64 will come early next week.

cheers,
--renato
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Dimitry Andric
In reply to this post by Hans Wennborg-2
On 17 Jul 2015, at 01:09, Hans Wennborg <[hidden email]> wrote:

>
> On Thu, Jul 16, 2015 at 3:47 PM, Dimitry Andric <[hidden email]> wrote:
>> On 17 Jul 2015, at 00:31, Hans Wennborg <[hidden email]> wrote:
>>>
>>> Dear testers,
>>>
>>> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>>>
>>> Upload binaries to the sftp and report your results to this thread.
>>>
>>> I'm sorry for the delay between branching and tagging. The changes to
>>> the release script took a little longer than I hoped.
>>>
>>> Thanks for helping with the release, and do let me know of any issues,
>>> questions, etc.
>>>
>>> The tracking bug for release blockers is PR24126.
>>
>> Is it OK to do an autoconf build?  The CMake build tries to build various components which do not yet work on FreeBSD, e.g. libcxxabi does not compile at all, libcompiler-rt has a bunch of test failures, etc.  Alternatively, can I disable these components in the CMake build locally?
>
> Yes, go ahead and use the autoconf build.
>
> Can you send a patch to test-release.sh that makes this default for
> FreeBSD? It's already the default for Darwin.
Here it is.  While here, I replaced the multiple calls to uname -s with a variable assignment.

It's currently building for FreeBSD 10.x i386 and amd64.

-Dimitry

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

use-autoconf-on-freebsd-too-1.diff (1K) Download Attachment
signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Dimitry Andric
On 19 Jul 2015, at 00:17, Dimitry Andric <[hidden email]> wrote:

>
> On 17 Jul 2015, at 01:09, Hans Wennborg <[hidden email]> wrote:
>>
>> On Thu, Jul 16, 2015 at 3:47 PM, Dimitry Andric <[hidden email]> wrote:
>>> On 17 Jul 2015, at 00:31, Hans Wennborg <[hidden email]> wrote:
>>>>
>>>> Dear testers,
>>>>
>>>> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>>>>
>>>> Upload binaries to the sftp and report your results to this thread.
>>>>
>>>> I'm sorry for the delay between branching and tagging. The changes to
>>>> the release script took a little longer than I hoped.
>>>>
>>>> Thanks for helping with the release, and do let me know of any issues,
>>>> questions, etc.
>>>>
>>>> The tracking bug for release blockers is PR24126.
>>>
>>> Is it OK to do an autoconf build?  The CMake build tries to build various components which do not yet work on FreeBSD, e.g. libcxxabi does not compile at all, libcompiler-rt has a bunch of test failures, etc.  Alternatively, can I disable these components in the CMake build locally?
>>
>> Yes, go ahead and use the autoconf build.
>>
>> Can you send a patch to test-release.sh that makes this default for
>> FreeBSD? It's already the default for Darwin.
>
> Here it is.  While here, I replaced the multiple calls to uname -s with a variable assignment.
>
> It's currently building for FreeBSD 10.x i386 and amd64.
Hm, strangely enough, this version of the script does not go further than the Phase 2 installation, and does not run any tests?  This used to work fine for the release_36 branch.

I think it is because of the "set -o pipefail" which was introduced, but I don't yet understand why this causes the Phase 2 installation to appear to fail, as there is no visible error.  I will investigate, or work around it by removing the pipefail option again.

-Dimitry


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Kun Ling-2
In reply to this post by Hans Wennborg-2
Hi Hans, 
      Test Result Report:  Ubuntu 15.04 AMD64 3.7.0-RC1 release . Everything works fine without any problem.
      
       SFTP Upload: Not done yet. Since do not have the SFTP access information.

Kun Ling
  
------------------ Original ------------------
Date:  Thu, Jul 16, 2015 02:31 PM
To:  "llvmdev"<[hidden email]>; "cfe-dev"<[hidden email]>; "lldb-dev"<[hidden email]>;
Cc:  "Ben Pope"<[hidden email]>; "Pavel Labath"<[hidden email]>; "Nikola Smiljanić"<[hidden email]>;
Subject:  [LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins
 
Dear testers,

3.7.0-rc1 was just tagged; please start your testing engines :-)

Upload binaries to the sftp and report your results to this thread.

I'm sorry for the delay between branching and tagging. The changes to
the release script took a little longer than I hoped.

Thanks for helping with the release, and do let me know of any issues,
questions, etc.

The tracking bug for release blockers is PR24126.

Cheers,
Hans
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Ben Pope
In reply to this post by Hans Wennborg-2
On Friday, July 17, 2015 06:31 AM, Hans Wennborg wrote:

> Dear testers,
>
> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>
> Upload binaries to the sftp and report your results to this thread.
>
> I'm sorry for the delay between branching and tagging. The changes to
> the release script took a little longer than I hoped.
>
> Thanks for helping with the release, and do let me know of any issues,
> questions, etc.

On Ubuntu 14.04 x64 (with cmake) I get these failures at Phase3 and no
tarball:

Failing Tests (18):
     AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.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
     SanitizerCommon-asan :: Linux/getpass.cc
     SanitizerCommon-asan :: Posix/decorate_proc_maps.cc
     SanitizerCommon-lsan :: Linux/getpass.cc
     SanitizerCommon-msan :: Linux/getpass.cc
     SanitizerCommon-msan :: Linux/signal_segv_handler.cc
     SanitizerCommon-msan :: Posix/decorate_proc_maps.cc
     SanitizerCommon-tsan :: Linux/getpass.cc
     SanitizerCommon-tsan :: Posix/decorate_proc_maps.cc

   Expected Passes    : 24006
   Expected Failures  : 131
   Unsupported Tests  : 377
   Unexpected Failures: 18


Ben

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [3.7 Release] RC1 has been tagged, Testing Phase I begins

Renato Golin-2
On 19 July 2015 at 09:36, Ben Pope <[hidden email]> wrote:
> On Ubuntu 14.04 x64 (with cmake) I get these failures at Phase3 and no
> tarball:

The tarball is an issue Hans is aware of. We're fixing it.

> Failing Tests (18):
>     AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc

Did you use to build compiler-rt on the previous (autoconf) releases?

If not, this might explain why you're only seeing these errors now.

cheers,
--renato
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
1234