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:
https://llvm.org/PR48917
https://llvm.org/PR48920
https://llvm.org/PR48919
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 49197 – [libcxx] Please merge 328261019f50a76b11fa625739cbf32ceb2ce2f7 into 12.0.0, 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