[6.0.0 Release] Release Candidate 2 tagged

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [Openmp-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged

Dennis Luehring via cfe-dev
On Sun, Feb 11, 2018 at 3:31 PM, Dimitry Andric <[hidden email]> wrote:

> On 9 Feb 2018, at 22:30, Dimitry Andric <[hidden email]> wrote:
>>
>> On 9 Feb 2018, at 22:11, Dimitry Andric via Openmp-dev <[hidden email]> wrote:
>>>
>>> On 9 Feb 2018, at 20:40, Dimitry Andric via cfe-dev <[hidden email]> wrote:
>>>>
>>>>> On 9 Feb 2018, at 10:20, Hans Wennborg <[hidden email]> wrote:
>>> ...
>>>>> What are all these test failures? Does it seems like they have a
>>>>> common root cause and do we have a bug for it?
>>> ...
>>>> The Clang Tools and Extra Tools Unit tests all appear to crash with:
>>>>
>>>>  exception_ptr not yet implemented
>>>
>>> This turns out to be caused by libc++ being compiled without -DLIBCXXRT.  (In the FreeBSD base system build, we always add this option, so libc++ knows how to handle exceptions.)
>>>
>>> In the libc++ CMakeFiles, it appears to be governed by LIBCXX_CXX_ABI_LIBNAME, but it isn't being set to the correct value of "cxxrt" on FreeBSD.  I am going to try the following diff:
>>>
>>> --- llvm.src/projects/libcxx/CMakeLists.txt
>>> +++ llvm.src/projects/libcxx/CMakeLists.txt
>>> @@ -135,6 +135,8 @@
>>>  elseif (APPLE)
>>>    set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
>>>    set(LIBCXX_CXX_ABI_SYSTEM 1)
>>> +  elseif (CMAKE_SYSTEM_NAME MATCHES "FreeBSD")
>>> +    set(LIBCXX_CXX_ABI_LIBNAME "libcxxrt")
>>>  else()
>>>    set(LIBCXX_CXX_ABI_LIBNAME "default")
>>>  endif()
>>
>> ... and unfortunately that didn't work, since the CMakeFiles are unable to find the libcxxrt headers:
>>
>> CMake Warning at projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:67 (message):
>>  Failed to find cxxabi.h
>> Call Stack (most recent call first):
>>  projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:112 (setup_abi_lib)
>>  projects/libcxx/CMakeLists.txt:428 (include)
>
> Ok, this turned out to be easier than I thought.  After applying https://reviews.llvm.org/D43166, the number of failed tests drops roughly by half (from 896 to 512):
>
>   Expected Passes    : 45381
>   Expected Failures  : 185
>   Unsupported Tests  : 2937
>   Unexpected Passes  : 1
>   Unexpected Failures: 521
>
> I am going to have a look at some other low hanging fruit, and I have also created a few PRs to merge test changes into 6.0.

Nice!

It sounds like most of this is stuff that's always been failing, so
I'm not going to worry too much, but it's very nice to see the error
numbers go down.

Thanks,
Hans
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [Openmp-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged

Dennis Luehring via cfe-dev
I noticed a problem with llvm-config.exe on Windows:

>"c:\Users\andy\llvm+clang-6.0.0rc2-win64-msvc-release\bin\llvm-config.exe" --system-libs
psapi.lib shell32.lib ole32.lib uuid.lib

But then when I link against LLVM and these libs, I get:

lld: error: LLVMSupport.lib(Process.obj): undefined symbol:
__imp_CryptAcquireContextW
lld: error: LLVMSupport.lib(RandomNumberGenerator.obj): undefined
symbol: __imp_CryptAcquireContextW
lld: error: LLVMSupport.lib(Signals.obj): undefined symbol: __imp_RegCloseKey
lld: error: LLVMSupport.lib(Signals.obj): undefined symbol: __imp_RegOpenKeyExA
lld: error: LLVMSupport.lib(Signals.obj): undefined symbol: __imp_RegGetValueW


It seems that Advapi32.lib is missing from the --system-libs list.

On Mon, Feb 12, 2018 at 4:16 AM, Hans Wennborg via llvm-dev
<[hidden email]> wrote:

> On Sun, Feb 11, 2018 at 3:31 PM, Dimitry Andric <[hidden email]> wrote:
>> On 9 Feb 2018, at 22:30, Dimitry Andric <[hidden email]> wrote:
>>>
>>> On 9 Feb 2018, at 22:11, Dimitry Andric via Openmp-dev <[hidden email]> wrote:
>>>>
>>>> On 9 Feb 2018, at 20:40, Dimitry Andric via cfe-dev <[hidden email]> wrote:
>>>>>
>>>>>> On 9 Feb 2018, at 10:20, Hans Wennborg <[hidden email]> wrote:
>>>> ...
>>>>>> What are all these test failures? Does it seems like they have a
>>>>>> common root cause and do we have a bug for it?
>>>> ...
>>>>> The Clang Tools and Extra Tools Unit tests all appear to crash with:
>>>>>
>>>>>  exception_ptr not yet implemented
>>>>
>>>> This turns out to be caused by libc++ being compiled without -DLIBCXXRT.  (In the FreeBSD base system build, we always add this option, so libc++ knows how to handle exceptions.)
>>>>
>>>> In the libc++ CMakeFiles, it appears to be governed by LIBCXX_CXX_ABI_LIBNAME, but it isn't being set to the correct value of "cxxrt" on FreeBSD.  I am going to try the following diff:
>>>>
>>>> --- llvm.src/projects/libcxx/CMakeLists.txt
>>>> +++ llvm.src/projects/libcxx/CMakeLists.txt
>>>> @@ -135,6 +135,8 @@
>>>>  elseif (APPLE)
>>>>    set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
>>>>    set(LIBCXX_CXX_ABI_SYSTEM 1)
>>>> +  elseif (CMAKE_SYSTEM_NAME MATCHES "FreeBSD")
>>>> +    set(LIBCXX_CXX_ABI_LIBNAME "libcxxrt")
>>>>  else()
>>>>    set(LIBCXX_CXX_ABI_LIBNAME "default")
>>>>  endif()
>>>
>>> ... and unfortunately that didn't work, since the CMakeFiles are unable to find the libcxxrt headers:
>>>
>>> CMake Warning at projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:67 (message):
>>>  Failed to find cxxabi.h
>>> Call Stack (most recent call first):
>>>  projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:112 (setup_abi_lib)
>>>  projects/libcxx/CMakeLists.txt:428 (include)
>>
>> Ok, this turned out to be easier than I thought.  After applying https://reviews.llvm.org/D43166, the number of failed tests drops roughly by half (from 896 to 512):
>>
>>   Expected Passes    : 45381
>>   Expected Failures  : 185
>>   Unsupported Tests  : 2937
>>   Unexpected Passes  : 1
>>   Unexpected Failures: 521
>>
>> I am going to have a look at some other low hanging fruit, and I have also created a few PRs to merge test changes into 6.0.
>
> Nice!
>
> It sounds like most of this is stuff that's always been failing, so
> I'm not going to worry too much, but it's very nice to see the error
> numbers go down.
>
> Thanks,
> Hans
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [6.0.0 Release] Release Candidate 2 tagged

Dennis Luehring via cfe-dev
In reply to this post by Dennis Luehring via cfe-dev
Am 2018-02-07 21:51, schrieb Hans Wennborg via llvm-dev:
> Dear testers,
>
> There's been a lot of merges since rc1, and hopefully the tests are in
> a better state now.
>
> 6.0.0-rc2 was just tagged, after r324506.
>
> Please test, let me know how it goes, and upload binaries.

Hi Hans,

I can't build the documentation:
<<<>>>/docs/ReleaseNotes.rst:91: WARNING: Title underline too short.

Changes to the Hexagon Target
-------------------------

(I think there are some more errors in ReleaseNotes.rst...)
This brings me to the question which versions of sphinx LLVM officially
supports?

Regards,
Jonas
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [6.0.0 Release] Release Candidate 2 tagged

Dennis Luehring via cfe-dev
On Tue, Feb 13, 2018 at 10:36 AM, Jonas Hahnfeld <[hidden email]> wrote:

> Am 2018-02-07 21:51, schrieb Hans Wennborg via llvm-dev:
>>
>> Dear testers,
>>
>> There's been a lot of merges since rc1, and hopefully the tests are in
>> a better state now.
>>
>> 6.0.0-rc2 was just tagged, after r324506.
>>
>> Please test, let me know how it goes, and upload binaries.
>
>
> Hi Hans,
>
> I can't build the documentation:
> <<<>>>/docs/ReleaseNotes.rst:91: WARNING: Title underline too short.
>
> Changes to the Hexagon Target
> -------------------------

Sorry, I noticed that just after I put in the tag. It's been fixed now.

There are more warnings, especially in some auto-generated files, but
they look benign.

I use -DSPHINX_WARNINGS_AS_ERRORS=OFF for my builds.

> (I think there are some more errors in ReleaseNotes.rst...)
> This brings me to the question which versions of sphinx LLVM officially
> supports?

I don't know if there's an officially supported version. I try to fix
the warnings I see, and will go through especially the release notes
before releasing, but I'm not sure we'll ever be warning clean.

Thanks,
Hans
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [Openmp-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged

Dennis Luehring via cfe-dev
In reply to this post by Dennis Luehring via cfe-dev
Hi Andrew,

On Mon, Feb 12, 2018 at 5:00 PM, Andrew Kelley <[hidden email]> wrote:

> I noticed a problem with llvm-config.exe on Windows:
>
>>"c:\Users\andy\llvm+clang-6.0.0rc2-win64-msvc-release\bin\llvm-config.exe" --system-libs
> psapi.lib shell32.lib ole32.lib uuid.lib
>
> But then when I link against LLVM and these libs, I get:
>
> lld: error: LLVMSupport.lib(Process.obj): undefined symbol:
> __imp_CryptAcquireContextW
> lld: error: LLVMSupport.lib(RandomNumberGenerator.obj): undefined
> symbol: __imp_CryptAcquireContextW
> lld: error: LLVMSupport.lib(Signals.obj): undefined symbol: __imp_RegCloseKey
> lld: error: LLVMSupport.lib(Signals.obj): undefined symbol: __imp_RegOpenKeyExA
> lld: error: LLVMSupport.lib(Signals.obj): undefined symbol: __imp_RegGetValueW
>
>
> It seems that Advapi32.lib is missing from the --system-libs list.

Can you file a bug blocking PR35804 to track it easier?

Thanks,
Hans

>
> On Mon, Feb 12, 2018 at 4:16 AM, Hans Wennborg via llvm-dev
> <[hidden email]> wrote:
>> On Sun, Feb 11, 2018 at 3:31 PM, Dimitry Andric <[hidden email]> wrote:
>>> On 9 Feb 2018, at 22:30, Dimitry Andric <[hidden email]> wrote:
>>>>
>>>> On 9 Feb 2018, at 22:11, Dimitry Andric via Openmp-dev <[hidden email]> wrote:
>>>>>
>>>>> On 9 Feb 2018, at 20:40, Dimitry Andric via cfe-dev <[hidden email]> wrote:
>>>>>>
>>>>>>> On 9 Feb 2018, at 10:20, Hans Wennborg <[hidden email]> wrote:
>>>>> ...
>>>>>>> What are all these test failures? Does it seems like they have a
>>>>>>> common root cause and do we have a bug for it?
>>>>> ...
>>>>>> The Clang Tools and Extra Tools Unit tests all appear to crash with:
>>>>>>
>>>>>>  exception_ptr not yet implemented
>>>>>
>>>>> This turns out to be caused by libc++ being compiled without -DLIBCXXRT.  (In the FreeBSD base system build, we always add this option, so libc++ knows how to handle exceptions.)
>>>>>
>>>>> In the libc++ CMakeFiles, it appears to be governed by LIBCXX_CXX_ABI_LIBNAME, but it isn't being set to the correct value of "cxxrt" on FreeBSD.  I am going to try the following diff:
>>>>>
>>>>> --- llvm.src/projects/libcxx/CMakeLists.txt
>>>>> +++ llvm.src/projects/libcxx/CMakeLists.txt
>>>>> @@ -135,6 +135,8 @@
>>>>>  elseif (APPLE)
>>>>>    set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
>>>>>    set(LIBCXX_CXX_ABI_SYSTEM 1)
>>>>> +  elseif (CMAKE_SYSTEM_NAME MATCHES "FreeBSD")
>>>>> +    set(LIBCXX_CXX_ABI_LIBNAME "libcxxrt")
>>>>>  else()
>>>>>    set(LIBCXX_CXX_ABI_LIBNAME "default")
>>>>>  endif()
>>>>
>>>> ... and unfortunately that didn't work, since the CMakeFiles are unable to find the libcxxrt headers:
>>>>
>>>> CMake Warning at projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:67 (message):
>>>>  Failed to find cxxabi.h
>>>> Call Stack (most recent call first):
>>>>  projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:112 (setup_abi_lib)
>>>>  projects/libcxx/CMakeLists.txt:428 (include)
>>>
>>> Ok, this turned out to be easier than I thought.  After applying https://reviews.llvm.org/D43166, the number of failed tests drops roughly by half (from 896 to 512):
>>>
>>>   Expected Passes    : 45381
>>>   Expected Failures  : 185
>>>   Unsupported Tests  : 2937
>>>   Unexpected Passes  : 1
>>>   Unexpected Failures: 521
>>>
>>> I am going to have a look at some other low hanging fruit, and I have also created a few PRs to merge test changes into 6.0.
>>
>> Nice!
>>
>> It sounds like most of this is stuff that's always been failing, so
>> I'm not going to worry too much, but it's very nice to see the error
>> numbers go down.
>>
>> Thanks,
>> Hans
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Release-testers] [6.0.0 Release] Release Candidate 2 tagged

Dennis Luehring via cfe-dev
In reply to this post by Dennis Luehring via cfe-dev
Hi Hans,

I'm seeing one unexpected failure:

    libc++ :: std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.put.area/pbump2gig.pass.cpp

Test logs show:

Standard Error:
--
terminating with uncaught exception of type std::length_error: basic_string
--

but only on my big endian MIPS machine. I have filed PR36373 for the above failure.

I've looked at the failures from Msan from the previous rc candidate, and have been unable to reproduce them. What
I have seen is that the observed test failures from rc1, rc1 investigations and rc2 are transient.

Binaries uploaded.

SHA256(clang+llvm-6.0.0-rc2-mipsel-linux-gnu.tar.xz)= 0e446f60a1649680a49b048ad1429d4e327d1839dbbc8b34f1bd81e3277a98ee
SHA256(clang+llvm-6.0.0-rc2-mips-linux-gnu.tar.xz)= bdec9b0fe00cfdeefe53b8e471b9266ad9a99dfd10eded5e078026f67a38650a
SHA256(clang+llvm-6.0.0-rc2-x86_64-linux-gnu-debian8.tar.xz)= e6a281885d2f0fbc4e00bdc34803f67bb756f19badef3f24ed3738b2244c57cc

Thanks,
Simon
________________________________________
From: Release-testers [[hidden email]] on behalf of Hans Wennborg via Release-testers [[hidden email]]
Sent: Wednesday, February 7, 2018 8:51 PM
To: Release-testers
Cc: llvm-dev; cfe-dev; openmp-dev ([hidden email]); LLDB Dev
Subject: [Release-testers] [6.0.0 Release] Release Candidate 2 tagged

Dear testers,

There's been a lot of merges since rc1, and hopefully the tests are in
a better state now.

6.0.0-rc2 was just tagged, after r324506.

Please test, let me know how it goes, and upload binaries.

Thanks,
Hans
_______________________________________________
Release-testers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Release-testers] [6.0.0 Release] Release Candidate 2 tagged

Dennis Luehring via cfe-dev
Thanks! I've added the binaries to http://prereleases.llvm.org/6.0.0/

On Tue, Feb 13, 2018 at 10:57 PM, Simon Dardis <[hidden email]> wrote:

> Hi Hans,
>
> I'm seeing one unexpected failure:
>
>     libc++ :: std/input.output/stream.buffers/streambuf/streambuf.protected/streambuf.put.area/pbump2gig.pass.cpp
>
> Test logs show:
>
> Standard Error:
> --
> terminating with uncaught exception of type std::length_error: basic_string
> --
>
> but only on my big endian MIPS machine. I have filed PR36373 for the above failure.
>
> I've looked at the failures from Msan from the previous rc candidate, and have been unable to reproduce them. What
> I have seen is that the observed test failures from rc1, rc1 investigations and rc2 are transient.
>
> Binaries uploaded.
>
> SHA256(clang+llvm-6.0.0-rc2-mipsel-linux-gnu.tar.xz)= 0e446f60a1649680a49b048ad1429d4e327d1839dbbc8b34f1bd81e3277a98ee
> SHA256(clang+llvm-6.0.0-rc2-mips-linux-gnu.tar.xz)= bdec9b0fe00cfdeefe53b8e471b9266ad9a99dfd10eded5e078026f67a38650a
> SHA256(clang+llvm-6.0.0-rc2-x86_64-linux-gnu-debian8.tar.xz)= e6a281885d2f0fbc4e00bdc34803f67bb756f19badef3f24ed3738b2244c57cc
>
> Thanks,
> Simon
> ________________________________________
> From: Release-testers [[hidden email]] on behalf of Hans Wennborg via Release-testers [[hidden email]]
> Sent: Wednesday, February 7, 2018 8:51 PM
> To: Release-testers
> Cc: llvm-dev; cfe-dev; openmp-dev ([hidden email]); LLDB Dev
> Subject: [Release-testers] [6.0.0 Release] Release Candidate 2 tagged
>
> Dear testers,
>
> There's been a lot of merges since rc1, and hopefully the tests are in
> a better state now.
>
> 6.0.0-rc2 was just tagged, after r324506.
>
> Please test, let me know how it goes, and upload binaries.
>
> Thanks,
> Hans
> _______________________________________________
> Release-testers mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
12