Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-06-26T20:46:12+00:00 2020-06-26T20:46:12+00:00 Eric Fiselier eric@efcs.ca 2020-04-09T21:39:40+00:00 urn:sha1:77d76b71d7df39b573dfa1e391096a040e9b7bd3 The use of the `&& ...` fold expression in std::array's deduction guides recursively builds a set of binary operator expressions of depth N where `N` is the number of elements in the initializer. This is problematic because arrays may be large, and instantiation depth is limited. This patch addresses the issue by flattening the SFINAE using the existing `__all` type trait. (cherry picked from commit c6eb584c64872fbb779df14acd31c1f3947f6e52) 2020-04-13T14:13:36+00:00 Tom Stellard tstellar@redhat.com 2020-04-08T14:22:49+00:00 urn:sha1:4822f2a6154742ab24e0266d6c4b0c2937d22ab7 2020-02-28T16:11:03+00:00 Hans Wennborg hans@chromium.org 2020-02-28T16:11:03+00:00 urn:sha1:4c6e5899859651d5f0907fc4d5752e616c1598c3 2020-02-20T14:32:05+00:00 Eric Fiselier eric@efcs.ca 2020-02-19T16:59:37+00:00 urn:sha1:7a18790ae2f4b92dc26b2be963e588c8837d0076 The libc++ __bit_iterator type has weird ABI calling conventions as a quirk of the implementation. The const bit iterator is trivial, but the non-const bit iterator is not because it declares a user-defined copy constructor. Changing this now is an ABI break, so this test ensures that each type is trivial/non-trivial as expected. The definition of 'non-trivial for the purposes of calls': A type is considered non-trivial for the purposes of calls if: * it has a non-trivial copy constructor, move constructor, or destructor, or * all of its copy and move constructors are deleted. (cherry picked from commit a829443cc7359ecf0f2de8f82519f511795675ec) 2020-02-19T09:32:36+00:00 Sergej Jaskiewicz jaskiewiczs@icloud.com 2020-01-21T16:40:34+00:00 urn:sha1:8dbe13ff509c60dececd9d93f7ffe86c5c4456a0 Summary: `platform.linux_distribution()` has been deprecated in Python 3.5 and removed in Python 3.8. Reviewers: bcain, bcraig, jroelofs, EricWF, mclow.lists, ldionne Reviewed By: jroelofs Subscribers: dexonsmith, christof, ldionne, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D72501 (cherry picked from commit 7b8dc8c57697e95fd0b1248e4494ecc0f929aba1) 2020-02-17T22:47:30+00:00 Aaron Puchert aaronpuchert@alice-dsl.net 2020-02-17T22:47:28+00:00 urn:sha1:4f53867ec27bde33479c7891c256225f2075945a Summary: Also fix the version for libcxxabi, which was stuck in the past. Reviewers: hans, mclow.lists Reviewed By: hans Subscribers: mgorny, christof, libcxx-commits, llvm-commits, ldionne Tags: #libc, #llvm Differential Revision: https://reviews.llvm.org/D74586 2020-02-05T15:23:07+00:00 Martin Storsjö martin@martin.st 2020-02-05T10:02:14+00:00 urn:sha1:d5361190993a5df779eee245a18ceb76a7947833 Differential Revision: https://reviews.llvm.org/D74029 2020-02-04T10:41:50+00:00 Martin Storsjö martin@martin.st 2019-10-28T08:39:44+00:00 urn:sha1:ca6b341bd5d7159d9e398eef1a787b649c5bc888 This fixes using non-default locales, which currently can crash when e.g. formatting numbers. Within the localeconv_l function, the per-thread locale is temporarily changed with __libcpp_locale_guard, then localeconv() is called, returning an lconv * struct pointer. When localeconv_l returns, the __libcpp_locale_guard dtor restores the per-thread locale back to the original. This invalidates the contents of the earlier returned lconv struct, and all C strings that are pointed to within it are also invalidated. Thus, to have an actually working localeconv_l function, the function needs to allocate some sort of storage for the returned contents, that stays valid for as long as the caller needs to use the returned struct. Extend the libcxx/win32 specific locale_t class with storage for a deep copy of a lconv struct, and change localeconv_l to take a reference to the locale_t, to allow it to store the returned lconv struct there. This works fine for libcxx itself, but wouldn't necessarily be right for a caller that uses libcxx's localeconv_l function. This fixes around 11 of libcxx's currently failing tests on windows. Differential Revision: https://reviews.llvm.org/D69505 (cherry picked from commit 7db4f2c6945a24a7d81dad3362700353e2ec369e) 2020-01-31T11:35:43+00:00 Sergej Jaskiewicz jaskiewiczs@icloud.com 2020-01-31T11:35:43+00:00 urn:sha1:3573526c0286c9461f0459be1a4592b2214594e7 This reverts commit 41f4dfd63ea0fe995ddfba1838aa5ed972cc1377. It broke standalone libc++ builds, which now try to use libc++abi from the wrong directory, instead of system instance. 2020-01-30T14:16:10+00:00 Dimitry Andric dimitry@andric.com 2020-01-30T07:00:28+00:00 urn:sha1:1a5959196da075e37ce55ea53b76a3db994197e6 Summary: FreeBSD got `timespec_get` support somewhere in the 12.x timeframe, but the C++ version check in its system headers was written incorrectly. This has now been fixed for both FreeBSD 13 and 12. Add checks for the corresponding `__FreeBSD_version` values, to define `_LIBCPP_HAS_TIMESPEC_GET` when the function is supported. Reviewers: emaste, EricWF, ldionne, mclow.lists Reviewed By: ldionne Subscribers: arichardson, krytarowski, christof, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D71522 (cherry picked from commit 5e416ba943b7c737deb8eca62756f7b4fa925845)