12.0.0-rc1 Release has been tagged

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
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

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
   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

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

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! :slight_smile:

(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.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