Hi Louis, ARM and AArch64 libcxx bots are still broken after this commit (host compiler is clang-8), logs are available here: http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/3143
Cheers, Yvan On Mon, 28 Sep 2020 at 23:44, Louis Dionne via Phabricator via cfe-commits <cfe-commits@lists.llvm.org> wrote: > > ldionne added a comment. > > In D68364#2294569 <https://reviews.llvm.org/D68364#2294569>, @jwakely wrote: > > > In D68364#2293971 <https://reviews.llvm.org/D68364#2293971>, @leonardchan > > wrote: > > > >> Is there a recommended way for working around this? We're using GCC > >> 10.2.1. Thanks. > > > > I don't think your implementation is valid. I think P0784 only allows > > new-expressions and calls to `std::allocator::allocate` in constexpr > > functions, not calls to `operator new`. > > Hmm, right. It's actually impossible to implement `__libcpp_allocate` in a > constexpr-friendly manner, since it's just allocating bytes. > > > Can you use something like `if (__builtin_is_constant_evaluated()) return > > new unsigned char[n];` and the equivalent in the corresponding deallocation > > function? > > That doesn't work, since we can't use `unsigned char`s as storage for > arbitrary `T`s in `constexpr`. > > I fixed it by marking `__libcpp_allocate` as non-`constexpr` and calling > `operator new` in `allocator<T>::allocate`, which seems to work on GCC. > > > Repository: > rG LLVM Github Monorepo > > CHANGES SINCE LAST ACTION > https://reviews.llvm.org/D68364/new/ > > https://reviews.llvm.org/D68364 > > _______________________________________________ > cfe-commits mailing list > cfe-commits@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
