https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The problem is the constexpr call cache we have, disabling it altogether like:
--- gcc/cp/constexpr.c 2020-01-04 11:19:50.585697766 +0100
+++ gcc/cp/constexpr.c 2020-01-04 11:18:42.000000000 +0100
@@ -2426,7 +2426,7 @@ cxx_eval_call_expression (const constexp
else if (!result)
result = void_node;
if (entry)
- entry->result = result;
+ entry->result = /*result*/error_mark_node;
}
/* The result of a constexpr function must be completely initialized.
fixes it.
Before the introduction of constexpr new/delete it was just fine to cache calls
that way, a constexpr call of the same constexpr function with the same
constant arguments with the same state of manifestly constant evaluation could
be reused.
I'm afraid that is no longer the case with constexpr new/delete, so I think we
need to avoid the caching if the call allocates something and doesn't
deallocate it before returning, or if it deallocates something it hasn't
allocated, because the call in that case isn't really stateless for the
constexpr evaluation.
Checking for the former could be easy, remember before the call how the length
of ctx->global->heap_vars and after the call, for any newly added elts verify
if they were all deallocated. To detect the deallocation without allocation
inside of the call we could perhaps add a counter for the deallocations and
compare that counter to the number of the allocations.
