https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369
--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #1) > So, first of all, is it a good idea to represent the HEAP variables through > artifical VAR_DECLs? That makes sense to me. > I guess in the outermost constexpr evaluation context we'd need to track > which of those we have allocated and deallocated and do the checking that at > the end of outermost constexpr evaluation no allocations are left around, Sounds right. > and that we don't deallocate something that hasn't been allocated. I'd expect that to be detected during evaluation when we try to deallocate something that isn't constant or isn't the address of one of these artificial VAR_DECLs. > As we don't have the actual dynamic type they will have at the end of new > expression We should really fix that. Perhaps we should delay lowering new-expressions until genericization time? > should we mark them some way and either allow the first > cxx_fold_indirect_ref or the above code to change their type the first time > they are stored? This would work, but wouldn't distinguish between a new-expression and the equivalent written by hand. I suppose a flag could make that distinction. > Is placement new ok in constexpr contexts or not? No, placement new is not replaceable. > Can the global replaceable allocation functions be marked constexpr by the > user? No. > For the constexpr dtors, we need to make sure to mark trivial dtors as > constexpr, and default dtors as constexpr if they satisfy the rules, verify > the restrictions for user defined constexpr dtors, and check for constexpr > dtor in literal type check. Plus guess for constexpr variables we need to > at some point verify they are constexpr destructible (but on a copy of the > variable value, such that changes to the value during destruction don't > modify the actual value of the variable we use normally). Right. I think that's implied by the passage "An object a is said to have constant destruction if ... for a hypothetical expression e whose only effect is to destroy a, e would be a core constant expression if the lifetime of a and its non-mutable subobjects (but not its mutable subobjects) were considered to start within e."
