12.0.0-rc1 Release has been tagged

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

12.0.0-rc1 Release has been tagged

shirley breuer via cfe-dev
Hi,

I've tagged the 12.0.0-rc1 release.  Testers can begin testing and upload binaries.

-Tom

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [lldb-dev] 12.0.0-rc1 Release has been tagged

shirley breuer via cfe-dev
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/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

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

build_llvm_1200-rc1._bat_ (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [lldb-dev] 12.0.0-rc1 Release has been tagged

shirley breuer via 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/D96498

It 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

On Thu, 28 Jan 2021 at 05:05, 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.

-Tom

_______________________________________________
lldb-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

build-woa64.patch (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] 12.0.0-rc1 Release has been tagged

shirley breuer via 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

signature.asc (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] 12.0.0-rc1 Release has been tagged

shirley breuer via 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
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] 12.0.0-rc1 Release has been tagged

shirley breuer via 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

fix-compiler-rt-1.diff (1K) Download Attachment
fix-libcxx-1.diff (722 bytes) Download Attachment
signature.asc (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] 12.0.0-rc1 Release has been tagged

shirley breuer via 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
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] 12.0.0-rc1 Release has been tagged

shirley breuer via 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
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] 12.0.0-rc1 Release has been tagged

shirley breuer via 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
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] 12.0.0-rc1 Release has been tagged

shirley breuer via 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
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] 12.0.0-rc1 Release has been tagged

shirley breuer via 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

signature.asc (230 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] 12.0.0-rc1 Release has been tagged

shirley breuer via cfe-dev
In reply to this post by shirley breuer via cfe-dev


On Fri, 19 Feb 2021 at 19:23, Tom Stellard <[hidden email]> wrote:
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