| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[libcxx][AIX] Switch build compiler to clang This patch switches the build compiler for AIX from ibm-clang to clang. ibm-clang++_r has -pthread by default, but clang for AIX doesn't, so -pthread had to be added to the test config. A bunch of tests now pass, so the XFAIL was removed. This patch also switch the build to use the visibility support available in clang-15 to control symbols exported by the shared library (AIX traditionally uses explicit export lists for this purpose). Reviewed By: #libc, #libc_abi, daltenty, #libunwind, ldionne Differential Revision: https://reviews.llvm.org/D127470 | 3 年前 | |
[libc++] Fix std::function's handling of blocks under Objc ARC Previously, some uses of std::function with blocks would crash when ARC was enabled. rdar://100907096 Differential Revision: https://reviews.llvm.org/D135706 (cherry picked from commit 0e4802bf45952b1120c52d4d1bf6bfa2800fd102) | 3 年前 | |
[libc++] Always query the compiler to find whether a type is always lockfree In https://llvm.org/D56913, we added an emulation for the __atomic_always_lock_free compiler builtin when compiling in Freestanding mode. However, the emulation did (and could not) give exactly the same answer as the compiler builtin, which led to a potential ABI break for e.g. enum classes. After speaking to the original author of D56913, we agree that the correct behavior is to instead always use the compiler builtin, since that provides a more accurate answer, and __atomic_always_lock_free is a purely front-end builtin which doesn't require any runtime support. Furthermore, it is available regardless of the Standard mode (see https://godbolt.org/z/cazf3ssYY). However, this patch does constitute an ABI break. As shown by https://godbolt.org/z/1eoex6zdK: - In LLVM <= 11.0.1, an atomic<enum class with 1 byte> would not contain a lock byte. - In LLVM >= 12.0.0, an atomic<enum class with 1 byte> would contain a lock byte. This patch breaks the ABI again to bring it back to 1 byte, which seems like the correct thing to do. Fixes #57440 Differential Revision: https://reviews.llvm.org/D133377 (cherry picked from commit f1a601fe88f99d52ca80617266897b217bcd4d64) | 3 年前 | |
[libc++][NFC] Fix signature of main in test (cherry picked from commit 27442728cd2e28bfaf0f2d89ad6378b4377e9c66) | 3 年前 | |
[libc++] Add clang-tidy for the tests Reviewed By: Mordante, huixie90, #libc Spies: aheejin, libcxx-commits Differential Revision: https://reviews.llvm.org/D129976 | 3 年前 | |
[libc++] Re-apply "Always build c++experimental.a"" This re-applies bb939931a1ad, which had been reverted by 09cebfb978de because it broke Chromium. The issues seen by Chromium should be addressed by 1d0f79558ca4. Differential Revision: https://reviews.llvm.org/D128927 | 3 年前 | |
[libc++] Allow specifying custom Lit config files Before this patch, the libc++ test suite first loads lit.site.cfg (generated by CMake), and then lit.cfg. It's also possible to load lit.cfg before lit.site.cfg and to point to a custom lit.site.cfg file using '--param=libcxx_site_config'. However, in that case, lit.cfg still relies on the site configuration filling up the 'config' object like the default lit.site.cfg file does, which isn't flexible enough. This commit simplifies the setup by having just a single Lit site config file per CMake configuration, and always loading exactly that config file. However, the config file to use can be selected when setting up CMake via the LIBCXX_TEST_CONFIG setting. Furthermore, the site configs are entirely standalone, which means that a new site config can be added that doesn't need to conform what's expected by config.py. Differential Revision: https://reviews.llvm.org/D81846 | 5 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 |