|
|
|
|
On Thu, Jan 28, 2021 at 5:05 AM Tom Stellard via lldb-dev
< [hidden email]> wrote:
>
> Hi,
>
> I've tagged the 12.0.0-rc1 release. Testers can begin testing and upload binaries.
Windows is ready:
$ sha256sum LLVM-12*.exe
599b7a1dc3a1c11977320c5146600820f3280a8d78b666d9dee99f2454f6c00a
LLVM-12.0.0-rc1-win32.exe
2d6b8b63d92c0e54ab8107b6c9c442ba03d08f6ae9522d5b4238cb195faae5ad
LLVM-12.0.0-rc1-win64.exe
I ran into a couple of test failures, and a build failure in the openmp runtime:
https://llvm.org/PR48917https://llvm.org/PR48920https://llvm.org/PR48919These are all getting addressed, but it means the uploaded package
doesn't include the openmp runtime, and some testing is disabled in
the batch file I used (attached).
Thanks,
Hans
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by shirley breuer via cfe-dev
Hello,
I've uploaded binaries for Windows on Arm: 081373cc76e88224020fea42eba2161d972f03bb83ebc055fb3cd4f2cfcdfb95 LLVM-12.0.0-rc1-woa64.exe
It was built from the current release/12.x branch (commit b46924ee) with two patches applied on top: - https://reviews.llvm.org/D96259- https://reviews.llvm.org/D96498It contains "clang;clang-tools-extra;lld;compiler-rt” projects. Compiler-RT has sanitizers disabled (MEMPROF and XRAY use sanitizer infrastucture). I.e., === + -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld;compiler-rt" ^ + -DCOMPILER_RT_BUILD_SANITIZERS=OFF ^ + -DCOMPILER_RT_BUILD_MEMPROF=OFF ^ + -DCOMPILER_RT_BUILD_XRAY=OFF ^ ===
I've attached the changes we had to make to llvm/utils/releases/build_llvm_package.bat. @Maxim Kuvyrkov is going to clean them up and post a patch in the next couple of weeks (he's been doing all the hard work, I'm just uploading).
This is the first time we're trying to provide a release for Windows on Arm, so if anyone has any comments or questions, feel free to send an email :)
Cheers, Diana _______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by shirley breuer via cfe-dev
On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev < [hidden email]> wrote:
>
> I've tagged the 12.0.0-rc1 release. Testers can begin testing and upload binaries.
During 12.0.0-rc1 test builds on FreeBSD, I encountered this unittest failure, which turned out to be caused by recent libc++ changes:
FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python
cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && /usr/local/bin/cmake -E env CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib /usr/local/bin/python3.7 -m unittest discover
EEEEEEEE
The 'EEEEEEEE' signifies 8 errors, which become more clear if "unittest discover" is run with the -f (fail immediately) and -v (verbose) options:
$ cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && /usr/local/bin/cmake -E env CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib /usr/local/bin/python3.7 -m unittest discover -f -v
test_access_specifiers (tests.cindex.test_access_specifiers.TestAccessSpecifiers)
Ensure that C++ access specifiers are available on cursors ... ERROR
======================================================================
ERROR: test_access_specifiers (tests.cindex.test_access_specifiers.TestAccessSpecifiers)
Ensure that C++ access specifiers are available on cursors
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 4173, in get_cindex_library
library = cdll.LoadLibrary(self.get_filename())
File "/usr/local/lib/python3.7/ctypes/__init__.py", line 442, in LoadLibrary
return self._dlltype(name)
File "/usr/local/lib/python3.7/ctypes/__init__.py", line 364, in __init__
self._handle = _dlopen(self._name, mode)
OSError: /home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: Undefined symbol "_ZnamSt11align_val_t"
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/test_access_specifiers.py", line 29, in test_access_specifiers
""", lang = 'cpp')
File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/util.py", line 41, in get_tu
source)])
File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 2812, in from_source
index = Index.create()
File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 2699, in create
return Index(conf.lib.clang_createIndex(excludeDecls, 0))
File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 212, in __get__
value = self.wrapped(instance)
File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 4147, in lib
lib = self.get_cindex_library()
File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 4178, in get_cindex_library
raise LibclangError(msg)
clang.cindex.LibclangError: /home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: Undefined symbol "_ZnamSt11align_val_t". To provide a path to libclang use Config.set_library_path() or Config.set_library_file().
----------------------------------------------------------------------
Ran 1 test in 0.027s
FAILED (errors=1)
It turns out that libc++.so.1 now depends on the symbol '_ZnamSt11align_val_t', which is 'operator new [](unsigned long, std::align_val_t)'. Embarassingly, libc++.so.1 has always depended on this C++17 specific variant of operator new. But FreeBSD's C++ ABI library, libcxxrt, has never supported this variant!
Previously, this never was a problem, because libc++ provided its own weak definitions of these operators. But recently the define _LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS was toggled to on by default, which disables those definitions. This happened in 9b40ee8eb0c194f4b2787801ac6f9ef8fc1b8f46 ("[libc++] Define new/delete in libc++abi only by default") by Louis Dionne.
While this is reasonable for the libc++abi situation, where it might lead to circular dependencies, I would like to turn the definitions on again in case libcxxrt is used for the C++ ABI, such as on FreeBSD.
If you think this is a reasonable approach, I will create a review for it. Otherwise, I will have to patch the test-release.sh script to pass -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON to the CMake command line on FreeBSD.
-Dimitry
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
> On Feb 13, 2021, at 12:04, Dimitry Andric < [hidden email]> wrote:
>
> On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev < [hidden email]> wrote:
>>
>> I've tagged the 12.0.0-rc1 release. Testers can begin testing and upload binaries.
>
> During 12.0.0-rc1 test builds on FreeBSD, I encountered this unittest failure, which turned out to be caused by recent libc++ changes:
>
> FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python
> cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && /usr/local/bin/cmake -E env CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib /usr/local/bin/python3.7 -m unittest discover
> EEEEEEEE
>
> The 'EEEEEEEE' signifies 8 errors, which become more clear if "unittest discover" is run with the -f (fail immediately) and -v (verbose) options:
>
> $ cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && /usr/local/bin/cmake -E env CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib /usr/local/bin/python3.7 -m unittest discover -f -v
> test_access_specifiers (tests.cindex.test_access_specifiers.TestAccessSpecifiers)
> Ensure that C++ access specifiers are available on cursors ... ERROR
>
> ======================================================================
> ERROR: test_access_specifiers (tests.cindex.test_access_specifiers.TestAccessSpecifiers)
> Ensure that C++ access specifiers are available on cursors
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 4173, in get_cindex_library
> library = cdll.LoadLibrary(self.get_filename())
> File "/usr/local/lib/python3.7/ctypes/__init__.py", line 442, in LoadLibrary
> return self._dlltype(name)
> File "/usr/local/lib/python3.7/ctypes/__init__.py", line 364, in __init__
> self._handle = _dlopen(self._name, mode)
> OSError: /home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: Undefined symbol "_ZnamSt11align_val_t"
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/test_access_specifiers.py", line 29, in test_access_specifiers
> """, lang = 'cpp')
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/util.py", line 41, in get_tu
> source)])
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 2812, in from_source
> index = Index.create()
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 2699, in create
> return Index(conf.lib.clang_createIndex(excludeDecls, 0))
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 212, in __get__
> value = self.wrapped(instance)
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 4147, in lib
> lib = self.get_cindex_library()
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 4178, in get_cindex_library
> raise LibclangError(msg)
> clang.cindex.LibclangError: /home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: Undefined symbol "_ZnamSt11align_val_t". To provide a path to libclang use Config.set_library_path() or Config.set_library_file().
>
> ----------------------------------------------------------------------
> Ran 1 test in 0.027s
>
> FAILED (errors=1)
>
> It turns out that libc++.so.1 now depends on the symbol '_ZnamSt11align_val_t', which is 'operator new [](unsigned long, std::align_val_t)'. Embarassingly, libc++.so.1 has always depended on this C++17 specific variant of operator new. But FreeBSD's C++ ABI library, libcxxrt, has never supported this variant!
>
> Previously, this never was a problem, because libc++ provided its own weak definitions of these operators. But recently the define _LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS was toggled to on by default, which disables those definitions. This happened in 9b40ee8eb0c194f4b2787801ac6f9ef8fc1b8f46 ("[libc++] Define new/delete in libc++abi only by default") by Louis Dionne.
>
> While this is reasonable for the libc++abi situation, where it might lead to circular dependencies, I would like to turn the definitions on again in case libcxxrt is used for the C++ ABI, such as on FreeBSD.
>
> If you think this is a reasonable approach, I will create a review for it. Otherwise, I will have to patch the test-release.sh script to pass -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON to the CMake command line on FreeBSD.
The correct approach would be to have a CMake cache file under libcxx/cmake/cache/FreeBSD.cmake that sets the right configuration for building libcxx as a system library on freebsd. That way, the cmake code itself can stay free of platform specific logic.
Also note that I remember asking vendors before making that change, but I guess I either forgot to ask Freebsd or you told me OK without thinking about this. I can’t verify which one happened because I’m on my phone, but I’ll check it out to make sure I have your contact information if I need to ask that sort of questions in the future. It could be useful to have some sort of libcxx-vendors group in Phabricator that I could tag whenever I want to ping you folks.
Please send a Phab and I’ll revise it quickly (probably on Monday morning).
Louis
>
> -Dimitry
>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by shirley breuer via cfe-dev
On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev < [hidden email]> wrote:
>
> I've tagged the 12.0.0-rc1 release. Testers can begin testing and upload binaries.
For 12.0.0 rc1, I have built and tested on both FreeBSD 11 and 12. I
used two patches, which are attached.
Main results on amd64-freebsd11:
Unsupported : 5557
Passed : 80122
Expectedly Failed : 246
Timed Out : 2
Failed : 95
Unexpectedly Passed: 2
Test suite results on amd64-freebsd11:
Passed: 2399
Failed: 3
Main results on amd64-freebsd12:
Unsupported : 5557
Passed : 80125
Expectedly Failed : 242
Timed Out : 4
Failed : 90
Unexpectedly Passed: 6
Test suite results on amd64-freebsd12:
Passed: 2399
Failed: 3
Main results on i386-freebsd11:
Unsupported : 3971
Passed : 76669
Expectedly Failed : 223
Failed : 51
Unexpectedly Passed: 1
Main results on i386-freebsd12:
Unsupported : 3971
Passed : 76672
Expectedly Failed : 221
Failed : 48
Unexpectedly Passed: 3
Uploaded:
SHA256 (clang+llvm-12.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 435e727287b9a3bf3f2da9bfec9d37b1118a59774885f0dd3597018f89515a4f
SHA256 (clang+llvm-12.0.0-rc1-amd64-unknown-freebsd12.tar.xz) = b2e49f56880fefe4bff2c45e74bfb55b2186fc16757a1b5d1b19f17dff9f49dd
SHA256 (clang+llvm-12.0.0-rc1-i386-unknown-freebsd11.tar.xz) = 10f0e81e4d516b46aff8dc22af1cc6eb9db0ec9c3a43b6941b51a6728255d311
SHA256 (clang+llvm-12.0.0-rc1-i386-unknown-freebsd12.tar.xz) = 077719695ebe6be1f55fb82eae483a9c550512809c6b272abfef9b2f84ada58e
-Dimitry
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
Hi,
I've built, tested and uploaded ARM and AArch64 binaries:
22bff83933ef52e605f89193165faaa6 clang+llvm-12.0.0-rc1-aarch64-linux-gnu.tar.xz
feb0f3d832a6a8a1265db0533cd9fc77 clang+llvm-12.0.0-rc1-armv7a-linux-gnueabihf.tar.xz
A few errors observed with ARMv7 LLD:
cfi-devirt-lld-armhf :: cross-dso/simple-fail.cpp
cfi-devirt-lld-armhf :: cross-dso/simple-pass.cpp
cfi-devirt-lld-armhf :: cross-dso/stats.cpp
cfi-devirt-lld-thinlto-armhf :: cross-dso/simple-fail.cpp
cfi-devirt-lld-thinlto-armhf :: cross-dso/simple-pass.cpp
cfi-devirt-lld-thinlto-armhf :: cross-dso/stats.cpp
cfi-standalone-lld-armhf :: cross-dso/simple-fail.cpp
cfi-standalone-lld-armhf :: cross-dso/simple-pass.cpp
cfi-standalone-lld-armhf :: cross-dso/stats.cpp
cfi-standalone-lld-thinlto-armhf :: cross-dso/simple-fail.cpp
cfi-standalone-lld-thinlto-armhf :: cross-dso/simple-pass.cpp
cfi-standalone-lld-thinlto-armhf :: cross-dso/stats.cpp
Cheers, Yvan
On Sun, 14 Feb 2021 at 23:24, Dimitry Andric via cfe-dev < [hidden email]> wrote: On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev <[hidden email]> wrote:
>
> I've tagged the 12.0.0-rc1 release. Testers can begin testing and upload binaries.
For 12.0.0 rc1, I have built and tested on both FreeBSD 11 and 12. I
used two patches, which are attached.
Main results on amd64-freebsd11:
Unsupported : 5557
Passed : 80122
Expectedly Failed : 246
Timed Out : 2
Failed : 95
Unexpectedly Passed: 2
Test suite results on amd64-freebsd11:
Passed: 2399
Failed: 3
Main results on amd64-freebsd12:
Unsupported : 5557
Passed : 80125
Expectedly Failed : 242
Timed Out : 4
Failed : 90
Unexpectedly Passed: 6
Test suite results on amd64-freebsd12:
Passed: 2399
Failed: 3
Main results on i386-freebsd11:
Unsupported : 3971
Passed : 76669
Expectedly Failed : 223
Failed : 51
Unexpectedly Passed: 1
Main results on i386-freebsd12:
Unsupported : 3971
Passed : 76672
Expectedly Failed : 221
Failed : 48
Unexpectedly Passed: 3
Uploaded:
SHA256 (clang+llvm-12.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 435e727287b9a3bf3f2da9bfec9d37b1118a59774885f0dd3597018f89515a4f
SHA256 (clang+llvm-12.0.0-rc1-amd64-unknown-freebsd12.tar.xz) = b2e49f56880fefe4bff2c45e74bfb55b2186fc16757a1b5d1b19f17dff9f49dd
SHA256 (clang+llvm-12.0.0-rc1-i386-unknown-freebsd11.tar.xz) = 10f0e81e4d516b46aff8dc22af1cc6eb9db0ec9c3a43b6941b51a6728255d311
SHA256 (clang+llvm-12.0.0-rc1-i386-unknown-freebsd12.tar.xz) = 077719695ebe6be1f55fb82eae483a9c550512809c6b272abfef9b2f84ada58e
-Dimitry
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by shirley breuer via cfe-dev
On 2/13/21 9:03 AM, Dimitry Andric wrote:
> On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev < [hidden email]> wrote:
>>
>> I've tagged the 12.0.0-rc1 release. Testers can begin testing and upload binaries.
>
> During 12.0.0-rc1 test builds on FreeBSD, I encountered this unittest failure, which turned out to be caused by recent libc++ changes:
>
> FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python
> cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && /usr/local/bin/cmake -E env CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib /usr/local/bin/python3.7 -m unittest discover
> EEEEEEEE
>
> The 'EEEEEEEE' signifies 8 errors, which become more clear if "unittest discover" is run with the -f (fail immediately) and -v (verbose) options:
>
> $ cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && /usr/local/bin/cmake -E env CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib /usr/local/bin/python3.7 -m unittest discover -f -v
> test_access_specifiers (tests.cindex.test_access_specifiers.TestAccessSpecifiers)
> Ensure that C++ access specifiers are available on cursors ... ERROR
>
> ======================================================================
> ERROR: test_access_specifiers (tests.cindex.test_access_specifiers.TestAccessSpecifiers)
> Ensure that C++ access specifiers are available on cursors
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 4173, in get_cindex_library
> library = cdll.LoadLibrary(self.get_filename())
> File "/usr/local/lib/python3.7/ctypes/__init__.py", line 442, in LoadLibrary
> return self._dlltype(name)
> File "/usr/local/lib/python3.7/ctypes/__init__.py", line 364, in __init__
> self._handle = _dlopen(self._name, mode)
> OSError: /home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: Undefined symbol "_ZnamSt11align_val_t"
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/test_access_specifiers.py", line 29, in test_access_specifiers
> """, lang = 'cpp')
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/util.py", line 41, in get_tu
> source)])
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 2812, in from_source
> index = Index.create()
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 2699, in create
> return Index(conf.lib.clang_createIndex(excludeDecls, 0))
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 212, in __get__
> value = self.wrapped(instance)
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 4147, in lib
> lib = self.get_cindex_library()
> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 4178, in get_cindex_library
> raise LibclangError(msg)
> clang.cindex.LibclangError: /home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: Undefined symbol "_ZnamSt11align_val_t". To provide a path to libclang use Config.set_library_path() or Config.set_library_file().
>
> ----------------------------------------------------------------------
> Ran 1 test in 0.027s
>
> FAILED (errors=1)
>
> It turns out that libc++.so.1 now depends on the symbol '_ZnamSt11align_val_t', which is 'operator new [](unsigned long, std::align_val_t)'. Embarassingly, libc++.so.1 has always depended on this C++17 specific variant of operator new. But FreeBSD's C++ ABI library, libcxxrt, has never supported this variant!
>
> Previously, this never was a problem, because libc++ provided its own weak definitions of these operators. But recently the define _LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS was toggled to on by default, which disables those definitions. This happened in 9b40ee8eb0c194f4b2787801ac6f9ef8fc1b8f46 ("[libc++] Define new/delete in libc++abi only by default") by Louis Dionne.
>
> While this is reasonable for the libc++abi situation, where it might lead to circular dependencies, I would like to turn the definitions on again in case libcxxrt is used for the C++ ABI, such as on FreeBSD.
>
> If you think this is a reasonable approach, I will create a review for it. Otherwise, I will have to patch the test-release.sh script to pass -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON to the CMake command line on FreeBSD.
>
I'm not sure what the best solution is. Can you file a bug for this and CC Louis.
-Tom
> -Dimitry
>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by shirley breuer via cfe-dev
On 2/13/21 1:44 PM, Louis Dionne wrote:
>
>
>> On Feb 13, 2021, at 12:04, Dimitry Andric < [hidden email]> wrote:
>>
>> On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev < [hidden email]> wrote:
>>>
>>> I've tagged the 12.0.0-rc1 release. Testers can begin testing and upload binaries.
>>
>> During 12.0.0-rc1 test builds on FreeBSD, I encountered this unittest failure, which turned out to be caused by recent libc++ changes:
>>
>> FAILED: tools/clang/bindings/python/tests/CMakeFiles/check-clang-python
>> cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && /usr/local/bin/cmake -E env CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib /usr/local/bin/python3.7 -m unittest discover
>> EEEEEEEE
>>
>> The 'EEEEEEEE' signifies 8 errors, which become more clear if "unittest discover" is run with the -f (fail immediately) and -v (verbose) options:
>>
>> $ cd /home/dim/llvm/12.0.0/llvm-project/clang/bindings/python && /usr/local/bin/cmake -E env CLANG_LIBRARY_PATH=/home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib /usr/local/bin/python3.7 -m unittest discover -f -v
>> test_access_specifiers (tests.cindex.test_access_specifiers.TestAccessSpecifiers)
>> Ensure that C++ access specifiers are available on cursors ... ERROR
>>
>> ======================================================================
>> ERROR: test_access_specifiers (tests.cindex.test_access_specifiers.TestAccessSpecifiers)
>> Ensure that C++ access specifiers are available on cursors
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 4173, in get_cindex_library
>> library = cdll.LoadLibrary(self.get_filename())
>> File "/usr/local/lib/python3.7/ctypes/__init__.py", line 442, in LoadLibrary
>> return self._dlltype(name)
>> File "/usr/local/lib/python3.7/ctypes/__init__.py", line 364, in __init__
>> self._handle = _dlopen(self._name, mode)
>> OSError: /home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: Undefined symbol "_ZnamSt11align_val_t"
>>
>> During handling of the above exception, another exception occurred:
>>
>> Traceback (most recent call last):
>> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/test_access_specifiers.py", line 29, in test_access_specifiers
>> """, lang = 'cpp')
>> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/tests/cindex/util.py", line 41, in get_tu
>> source)])
>> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 2812, in from_source
>> index = Index.create()
>> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 2699, in create
>> return Index(conf.lib.clang_createIndex(excludeDecls, 0))
>> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 212, in __get__
>> value = self.wrapped(instance)
>> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 4147, in lib
>> lib = self.get_cindex_library()
>> File "/home/dim/llvm/12.0.0/llvm-project/clang/bindings/python/clang/cindex.py", line 4178, in get_cindex_library
>> raise LibclangError(msg)
>> clang.cindex.LibclangError: /home/dim/obj/llvmorg-12.0.0-rc1-2-gdf959fc2eb7e-1/lib/../lib/libc++.so.1: Undefined symbol "_ZnamSt11align_val_t". To provide a path to libclang use Config.set_library_path() or Config.set_library_file().
>>
>> ----------------------------------------------------------------------
>> Ran 1 test in 0.027s
>>
>> FAILED (errors=1)
>>
>> It turns out that libc++.so.1 now depends on the symbol '_ZnamSt11align_val_t', which is 'operator new [](unsigned long, std::align_val_t)'. Embarassingly, libc++.so.1 has always depended on this C++17 specific variant of operator new. But FreeBSD's C++ ABI library, libcxxrt, has never supported this variant!
>>
>> Previously, this never was a problem, because libc++ provided its own weak definitions of these operators. But recently the define _LIBCPP_DISABLE_NEW_DELETE_DEFINITIONS was toggled to on by default, which disables those definitions. This happened in 9b40ee8eb0c194f4b2787801ac6f9ef8fc1b8f46 ("[libc++] Define new/delete in libc++abi only by default") by Louis Dionne.
>>
>> While this is reasonable for the libc++abi situation, where it might lead to circular dependencies, I would like to turn the definitions on again in case libcxxrt is used for the C++ ABI, such as on FreeBSD.
>>
>> If you think this is a reasonable approach, I will create a review for it. Otherwise, I will have to patch the test-release.sh script to pass -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON to the CMake command line on FreeBSD.
>
> The correct approach would be to have a CMake cache file under libcxx/cmake/cache/FreeBSD.cmake that sets the right configuration for building libcxx as a system library on freebsd. That way, the cmake code itself can stay free of platform specific logic.
>
> Also note that I remember asking vendors before making that change, but I guess I either forgot to ask Freebsd or you told me OK without thinking about this. I can’t verify which one happened because I’m on my phone, but I’ll check it out to make sure I have your contact information if I need to ask that sort of questions in the future. It could be useful to have some sort of libcxx-vendors group in Phabricator that I could tag whenever I want to ping you folks.
>
> Please send a Phab and I’ll revise it quickly (probably on Monday morning).
>
Has this been fixed in the branch yet?
-Tom
> Louis
>
>>
>> -Dimitry
>>
>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by shirley breuer via cfe-dev
On 2/19/21 7:07 AM, Yvan Roux wrote:
> Hi,
>
> I've built, tested and uploaded ARM and AArch64 binaries:
>
> 22bff83933ef52e605f89193165faaa6 clang+llvm-12.0.0-rc1-aarch64-linux-gnu.tar.xz
> feb0f3d832a6a8a1265db0533cd9fc77 clang+llvm-12.0.0-rc1-armv7a-linux-gnueabihf.tar.xz
>
Which hash algorithm did you use? Also can you post the file sizes?
-Tom
> A few errors observed with ARMv7 LLD:
>
> cfi-devirt-lld-armhf :: cross-dso/simple-fail.cpp
> cfi-devirt-lld-armhf :: cross-dso/simple-pass.cpp
> cfi-devirt-lld-armhf :: cross-dso/stats.cpp
> cfi-devirt-lld-thinlto-armhf :: cross-dso/simple-fail.cpp
> cfi-devirt-lld-thinlto-armhf :: cross-dso/simple-pass.cpp
> cfi-devirt-lld-thinlto-armhf :: cross-dso/stats.cpp
> cfi-standalone-lld-armhf :: cross-dso/simple-fail.cpp
> cfi-standalone-lld-armhf :: cross-dso/simple-pass.cpp
> cfi-standalone-lld-armhf :: cross-dso/stats.cpp
> cfi-standalone-lld-thinlto-armhf :: cross-dso/simple-fail.cpp
> cfi-standalone-lld-thinlto-armhf :: cross-dso/simple-pass.cpp
> cfi-standalone-lld-thinlto-armhf :: cross-dso/stats.cpp
>
> Cheers,
> Yvan
>
>
> On Sun, 14 Feb 2021 at 23:24, Dimitry Andric via cfe-dev < [hidden email] <mailto: [hidden email]>> wrote:
>
> On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev < [hidden email] <mailto: [hidden email]>> wrote:
> >
> > I've tagged the 12.0.0-rc1 release. Testers can begin testing and upload binaries.
>
> For 12.0.0 rc1, I have built and tested on both FreeBSD 11 and 12. I
> used two patches, which are attached.
>
>
> Main results on amd64-freebsd11:
>
> Unsupported : 5557
> Passed : 80122
> Expectedly Failed : 246
> Timed Out : 2
> Failed : 95
> Unexpectedly Passed: 2
>
> Test suite results on amd64-freebsd11:
>
> Passed: 2399
> Failed: 3
>
>
> Main results on amd64-freebsd12:
>
> Unsupported : 5557
> Passed : 80125
> Expectedly Failed : 242
> Timed Out : 4
> Failed : 90
> Unexpectedly Passed: 6
>
> Test suite results on amd64-freebsd12:
>
> Passed: 2399
> Failed: 3
>
>
> Main results on i386-freebsd11:
>
> Unsupported : 3971
> Passed : 76669
> Expectedly Failed : 223
> Failed : 51
> Unexpectedly Passed: 1
>
>
> Main results on i386-freebsd12:
>
> Unsupported : 3971
> Passed : 76672
> Expectedly Failed : 221
> Failed : 48
> Unexpectedly Passed: 3
>
>
> Uploaded:
> SHA256 (clang+llvm-12.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 435e727287b9a3bf3f2da9bfec9d37b1118a59774885f0dd3597018f89515a4f
> SHA256 (clang+llvm-12.0.0-rc1-amd64-unknown-freebsd12.tar.xz) = b2e49f56880fefe4bff2c45e74bfb55b2186fc16757a1b5d1b19f17dff9f49dd
> SHA256 (clang+llvm-12.0.0-rc1-i386-unknown-freebsd11.tar.xz) = 10f0e81e4d516b46aff8dc22af1cc6eb9db0ec9c3a43b6941b51a6728255d311
> SHA256 (clang+llvm-12.0.0-rc1-i386-unknown-freebsd12.tar.xz) = 077719695ebe6be1f55fb82eae483a9c550512809c6b272abfef9b2f84ada58e
>
> -Dimitry
> _______________________________________________
> cfe-dev mailing list
> [hidden email] <mailto: [hidden email]>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev < https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by shirley breuer via cfe-dev
On 19 Feb 2021, at 19:14, Tom Stellard < [hidden email]> wrote:
>
> On 2/13/21 1:44 PM, Louis Dionne wrote:
>>> On Feb 13, 2021, at 12:04, Dimitry Andric < [hidden email]> wrote:
>>> On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev < [hidden email]> wrote:
>>>>
>>>> I've tagged the 12.0.0-rc1 release. Testers can begin testing and upload binaries.
>>>
>>> During 12.0.0-rc1 test builds on FreeBSD, I encountered this unittest failure, which turned out to be caused by recent libc++ changes:
...
>>> If you think this is a reasonable approach, I will create a review for it. Otherwise, I will have to patch the test-release.sh script to pass -DLIBCXX_ENABLE_NEW_DELETE_DEFINITIONS=ON to the CMake command line on FreeBSD.
>> The correct approach would be to have a CMake cache file under libcxx/cmake/cache/FreeBSD.cmake that sets the right configuration for building libcxx as a system library on freebsd. That way, the cmake code itself can stay free of platform specific logic.
>> Also note that I remember asking vendors before making that change, but I guess I either forgot to ask Freebsd or you told me OK without thinking about this. I can’t verify which one happened because I’m on my phone, but I’ll check it out to make sure I have your contact information if I need to ask that sort of questions in the future. It could be useful to have some sort of libcxx-vendors group in Phabricator that I could tag whenever I want to ping you folks.
>> Please send a Phab and I’ll revise it quickly (probably on Monday morning).
>
> Has this been fixed in the branch yet?
Yes, I submitted https://bugs.llvm.org/show_bug.cgi?id=49197, and you merged the fix in d14016d869ac. Thanks! :)
(That said, more work should probably be done on this particular issue, but the merged fix is good enough for the release.)
-Dimitry
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by shirley breuer via cfe-dev
On 2/19/21 7:07 AM, Yvan Roux wrote:
> Hi,
>
> I've built, tested and uploaded ARM and AArch64 binaries:
>
> 22bff83933ef52e605f89193165faaa6 clang+llvm-12.0.0-rc1-aarch64-linux-gnu.tar.xz
> feb0f3d832a6a8a1265db0533cd9fc77 clang+llvm-12.0.0-rc1-armv7a-linux-gnueabihf.tar.xz
>
Which hash algorithm did you use? Also can you post the file sizes?
Oups sorry, it was md5sum and sizes are:
aarch64 366M armv7 338M
-Tom
> A few errors observed with ARMv7 LLD:
>
> cfi-devirt-lld-armhf :: cross-dso/simple-fail.cpp
> cfi-devirt-lld-armhf :: cross-dso/simple-pass.cpp
> cfi-devirt-lld-armhf :: cross-dso/stats.cpp
> cfi-devirt-lld-thinlto-armhf :: cross-dso/simple-fail.cpp
> cfi-devirt-lld-thinlto-armhf :: cross-dso/simple-pass.cpp
> cfi-devirt-lld-thinlto-armhf :: cross-dso/stats.cpp
> cfi-standalone-lld-armhf :: cross-dso/simple-fail.cpp
> cfi-standalone-lld-armhf :: cross-dso/simple-pass.cpp
> cfi-standalone-lld-armhf :: cross-dso/stats.cpp
> cfi-standalone-lld-thinlto-armhf :: cross-dso/simple-fail.cpp
> cfi-standalone-lld-thinlto-armhf :: cross-dso/simple-pass.cpp
> cfi-standalone-lld-thinlto-armhf :: cross-dso/stats.cpp
>
> Cheers,
> Yvan
>
>
> On Sun, 14 Feb 2021 at 23:24, Dimitry Andric via cfe-dev <[hidden email] <mailto:[hidden email]>> wrote:
>
> On 28 Jan 2021, at 05:05, Tom Stellard via llvm-dev <[hidden email] <mailto:[hidden email]>> wrote:
> >
> > I've tagged the 12.0.0-rc1 release. Testers can begin testing and upload binaries.
>
> For 12.0.0 rc1, I have built and tested on both FreeBSD 11 and 12. I
> used two patches, which are attached.
>
>
> Main results on amd64-freebsd11:
>
> Unsupported : 5557
> Passed : 80122
> Expectedly Failed : 246
> Timed Out : 2
> Failed : 95
> Unexpectedly Passed: 2
>
> Test suite results on amd64-freebsd11:
>
> Passed: 2399
> Failed: 3
>
>
> Main results on amd64-freebsd12:
>
> Unsupported : 5557
> Passed : 80125
> Expectedly Failed : 242
> Timed Out : 4
> Failed : 90
> Unexpectedly Passed: 6
>
> Test suite results on amd64-freebsd12:
>
> Passed: 2399
> Failed: 3
>
>
> Main results on i386-freebsd11:
>
> Unsupported : 3971
> Passed : 76669
> Expectedly Failed : 223
> Failed : 51
> Unexpectedly Passed: 1
>
>
> Main results on i386-freebsd12:
>
> Unsupported : 3971
> Passed : 76672
> Expectedly Failed : 221
> Failed : 48
> Unexpectedly Passed: 3
>
>
> Uploaded:
> SHA256 (clang+llvm-12.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 435e727287b9a3bf3f2da9bfec9d37b1118a59774885f0dd3597018f89515a4f
> SHA256 (clang+llvm-12.0.0-rc1-amd64-unknown-freebsd12.tar.xz) = b2e49f56880fefe4bff2c45e74bfb55b2186fc16757a1b5d1b19f17dff9f49dd
> SHA256 (clang+llvm-12.0.0-rc1-i386-unknown-freebsd11.tar.xz) = 10f0e81e4d516b46aff8dc22af1cc6eb9db0ec9c3a43b6941b51a6728255d311
> SHA256 (clang+llvm-12.0.0-rc1-i386-unknown-freebsd12.tar.xz) = 077719695ebe6be1f55fb82eae483a9c550512809c6b272abfef9b2f84ada58e
>
> -Dimitry
> _______________________________________________
> cfe-dev mailing list
> [hidden email] <mailto:[hidden email]>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
Locked
build_llvm_1200-rc1._bat_ (7K)