Re: [lldb-dev] [llvm-dev] [6.0.0 Release] Release Candidate 2 tagged
On Tue, Feb 13, 2018 at 10:36 AM, Jonas Hahnfeld 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 ___ 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] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged
Hi Andrew, On Mon, Feb 12, 2018 at 5:00 PM, Andrew Kelley 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 > wrote: >> On Sun, Feb 11, 2018 at 3:31 PM, Dimitry Andric wrote: >>> On 9 Feb 2018, at 22:30, Dimitry Andric wrote: On 9 Feb 2018, at 22:11, Dimitry Andric via Openmp-dev wrote: > > On 9 Feb 2018, at 20:40, Dimitry Andric via cfe-dev > wrote: >> >>> On 9 Feb 2018, at 10:20, Hans Wennborg 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 >> 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] [Bug 36365] New: Weird MI '-break-disable' error message
https://bugs.llvm.org/show_bug.cgi?id=36365 Bug ID: 36365 Summary: Weird MI '-break-disable' error message Product: lldb Version: 6.0 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: danti...@nvidia.com CC: llvm-b...@lists.llvm.org MI command '-break-disable' reports a weird error message for a non-existing breakpoint number. Example: (gdb) -break-disable 111 ^error,msg="Command '0'. Breakpoint 'Command '%s'. Breakpoint '%s' invalid' invalid" Probably it should look similar to '-break-delete' instead: (gdb) -break-delete 111 ^error,msg="Command 'break-delete'. Breakpoint '111' invalid" -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged
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 [release-testers-boun...@lists.llvm.org] on behalf of Hans Wennborg via Release-testers [release-test...@lists.llvm.org] Sent: Wednesday, February 7, 2018 8:51 PM To: Release-testers Cc: llvm-dev; cfe-dev; openmp-dev (openmp-...@lists.llvm.org); 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 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
