rsmith added a comment. In D68364#2299336 <https://reviews.llvm.org/D68364#2299336>, @ldionne wrote:
> In D68364#2294569 <https://reviews.llvm.org/D68364#2294569>, @jwakely wrote: > >> 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. Right, we need to rely on implementation magic. I wrote up a document proposing how to do this <https://docs.google.com/document/d/1vTtCyAhSlu4ui5-wgMNLO-JzJCMIw86tNj882RDRUnI/edit> a year or so ago, and shared it with some GCC folks (I don't remember whether it was mailed to the GCC mailing list or just to Jason or what) suggesting that we follow option 3 of that doc -- in particular, this permits calls to `operator new` "//transitively// within a member of `std::allocator<T>`" (emphasis mine), precisely so that stdlib implementations can pull out helper functions as libc++ does, and don't need to branch on `is_constant_evaluated()` for this at all. That said, this is all vendor extension territory, and GCC is of course under no obligation to follow my proposal, and indeed seems not to have followed this detail of it. So be it. But... there's no question of "valid" here :) 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
