[C++ PATCH] Avoid caching constexpr calls that allocate something that they don't deallocate or vice versa (PR c++/91369)

[Jason Merrill]

On 1/5/20 8:04 AM, Jakub Jelinek wrote:
> Hi!
> 
> The caching of constexpr calls breaks the following testcase.
> The problem is that constexpr calls that allocate from heap something
> that they don't deallocate or calls that deallocate something they haven't
> allocated aren't stateless for the constexpr context and in each outermost
> constexpr evaluation the allocations will produce different artificial heap
> VAR_DECLs.  In the testcase a function allocates something that the caller
> is supposed to deallocate, so when we call it second time (e.g. from
> different function) with the same constant arguments, we get the cached
> result that contains address of the heap VAR_DECL from the earlier
> evaluation and error trying to free something we haven't allocated (in the
> same outermost constexpr evaluation).  Similarly, a constexpr call could
> deallocate something the caller is supposed to allocate, if we cache such
> call, we wouldn't actually deallocate it and complain the allocation has not
> been deallocated.
> 
> Fixed by making sure we only cache calls that either don't perform any
> allocations/deallocations, or perform exactly as many allocations and
> deallocations and all those new allocations (new additions to heap_vars,
> to which we only add, never remove) have been deallocated (checking just
> numbers is not good enough, we might perform 3 allocations and 3
> deallocations, e.g. deallocate 2 of those allocations and one passed to the
> call from the caller and pass the still allocated address to the caller.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

> 2020-01-05  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR c++/91369
> 	* constexpr.c (struct constexpr_global_ctx): Add heap_alloc_count
> 	member, initialize it to zero in ctor.
> 	(cxx_eval_call_expression): Bump heap_dealloc_count when deleting
> 	a heap object.  Don't cache calls to functions which allocate some
> 	heap objects and don't deallocate them or deallocate some heap
> 	objects they didn't allocate.