Hi,
I've tagged the 12.0.0-rc1 release. Testers can begin testing and upload binaries.
-Tom
Good morning,
I’m testing this on PowerPC; Power8 builds fine but on Power9 I am currently running into this error while building:
...random_shuffle.cpp.o -c /home/conanap/llvm/community/llvm-project/libcxx/src/random_shuffle.cpp
In file included from /home/conanap/llvm/community/llvm-project/libcxx/src/random_shuffle.cpp:10:
In file included from /home/conanap/12rc1/stage2/build/include/c++/v1/random:1680:
In file included from /home/conanap/12rc1/stage2/build/include/c++/v1/cmath:308:
/home/conanap/12rc1/stage2/build/include/c++/v1/math.h:383:12: error: expected '(' for function-style cast or type construction
return fpclassify(__lcpp_x);
^~~~~~~~~~~~~~~~~~~~
/usr/include/math.h:604:25: note: expanded from macro 'fpclassify'
# define fpclassify(x) __MATH_TG ((x), __fpclassify, (x))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/math.h:546:54: note: expanded from macro '__MATH_TG'
(__builtin_types_compatible_p (__typeof (TG_ARG), float), \
~~~~~~~~~~~~~~~~~^
This is a blocker for P9 testing unfortunately. Has anyone else run into this problem?
I’ve also attached the log for reference; there’s a lot more of the same or similar errors.
Regards,
Albion
build.log (45.3 KB)
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:
These 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
build_llvm_1200-rc1.bat|attachment (5.16 KB)
Uploaded Ubuntu 20.10 with lldb.
sha256sum clang+llvm-12.0.0-rc1-x86_64-linux-gnu-ubuntu-20.10.tar.xz
0ee9c6e3adc52eb4778e796441f0bedf178fe550e9898ded65276cf8871eea63
Failed Tests (20):
SanitizerCommon-asan-i386-Linux :: Linux/crypt_r.cpp
SanitizerCommon-asan-i386-Linux :: Posix/crypt.cpp
SanitizerCommon-lsan-i386-Linux :: Linux/crypt_r.cpp
SanitizerCommon-lsan-i386-Linux :: Posix/crypt.cpp
SanitizerCommon-ubsan-i386-Linux :: Linux/crypt_r.cpp
SanitizerCommon-ubsan-i386-Linux :: Posix/crypt.cpp
libarcher :: races/task-dependency.c
libarcher :: races/task-taskgroup-unrelated.c
libarcher :: races/task-taskwait-nested.c
libarcher :: races/task-two.c
libarcher :: task/task-barrier.c
libarcher :: task/task-create.c
libarcher :: task/task-dependency.c
libarcher :: task/task-taskgroup-nested.c
libarcher :: task/task-taskgroup.c
libarcher :: task/task-taskwait-nested.c
libarcher :: task/task-taskwait.c
libarcher :: task/task_early_fulfill.c
libarcher :: task/task_late_fulfill.c
lldb-api :: tools/lldb-vscode/runInTerminal/TestVSCode_runInTerminal.py
Testing Time: 549.10s
Unsupported : 3416
Passed : 84154
Expectedly Failed: 266
Failed : 20
Created the following bugs for the above failed tests.
Bug 48946 - skipping incompatible /usr/lib/x86_64-linux-gnu/libcrypt.so when searching for -lcrypt
Bug 48947 - FAIL: libarcher :: races/task-taskgroup-unrelated.c - release 12.0.0-rc1
Bug 48948 - FAIL: libarcher :: races/task-dependency.c - release 12.0.0-rc1
Bug 48949 - FAIL: libarcher :: races/task-taskwait-nested.c - release 12.0.0-rc1
Bug 48950 - FAIL: libarcher :: races/task-two.c - release 12.0.0-rc1
Bug 48951 - FAIL: libarcher :: task/task-create.c - release 12.0.0-rc1
Bug 48952 - FAIL: libarcher :: task/task-barrier.c - release 12.0.0-rc1
Bug 48953 - FAIL: libarcher :: task/task-taskgroup-nested.c- release 12.0.0-rc1
Bug 48954 - FAIL: libarcher :: task/task-dependency.c - release 12.0.0-rc1
Bug 48955 - FAIL: libarcher :: task/task-taskgroup.c - release 12.0.0-rc1
Bug 48956 - FAIL: libarcher :: task/task-taskwait-nested.c - release 12.0.0-rc1
Bug 48957 - FAIL: libarcher :: task/task-taskwait.c - release 12.0.0-rc1
Bug 48958 - FAIL: libarcher :: task/task_early_fulfill.c - release 12.0.0-rc1
Bug 48959 - FAIL: libarcher :: task/task_late_fulfill.c - release 12.0.0-rc1
Bug 48960 - FAIL: lldb-api :: tools/lldb-vscode/runInTerminal/TestVSCode_runInTerminal.py
Test suite
Testing Time: 990.98s
Passed: 2405
Neil Nelson
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:
It contains "clang;clang-tools-extra;lld;compiler-rt” projects. Compiler-RT has sanitizers disabled (MEMPROF and XRAY use sanitizer infrastucture). I.e.,
build-woa64.patch (6.92 KB)
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
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
EEEEEEEEThe '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.027sFAILED (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
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
fix-compiler-rt-1.diff (1.05 KB)
fix-libcxx-1.diff (711 Bytes)
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
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
EEEEEEEEThe '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.027sFAILED (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
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
EEEEEEEEThe '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.027sFAILED (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
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
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
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.xzWhich hash algorithm did you use? Also can you post the file sizes?
Oups sorry, it was md5sum and sizes are:
aarch64 366M
armv7 338M