[Bug c++/70594] [6 Regression] -fcompare-debug failure

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594

--- Comment #9 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Nathan Sidwell from comment #7)
> The change in debug  generation causes purtabations in  when GC happens. 
> Such that in onecase we find  a cached result, and in the other case we do
> not.  When we don't we end up here:
> 
> 0  allocate_decl_uid () at ../../../src/gcc/tree.c:990
> #1  0x0000000001362a01 in copy_node_stat (node=0x7ffff6093e10) at
> ../../../src/gcc/tree.c:1157
> #2  0x00000000010f1a97 in copy_decl_no_change (decl=0x7ffff6093e10,
> id=0x7fffffffb120) at ../../../src/gcc/tree-inline.c:5444
> #3  0x00000000010e0ebe in remap_decl (decl=0x7ffff6093e10,
> id=0x7fffffffb120) at ../../../src/gcc/tree-inline.c:357
> #4  0x00000000010f45fe in copy_fn (fn=0x7ffff6168c40, parms=@0x7ffff6683a28:
> 0x0, result=@0x7ffff6683a30: 0xafafafafafafafaf)
>     at ../../../src/gcc/tree-inline.c:6148
> #5  0x00000000009ec170 in get_fundef_copy (fun=0x7ffff6168c40) at
> ../../../src/gcc/cp/constexpr.c:1021
> 
> copy_node_stat allocates  a new  UID for decls.  so despite its name
> 'copy_decl_no_change' does cause a change.
> 
> That decl never escapes out of the const-expr machinery, but of cause causes
> later decls to have different numberings.  (which is what we're observing).
> 
> I suppose the constexpr machinery could restore the next_decl_uid (and
> perhaps others?) after copy_fn -- or somewhere in that call chain.  But that
> does seem rather icky.
> 
> Alternatively copy_decl_no_change could not allocate new UIDs?

The decls belonging to a copy of a function must have new UIDs though because
their uids are used to track their mutable values (within the
constexpr_ctx::values hash_map).  So if the decls of two copies of the same
function didn't have different uids then e.g. recursive function calls wouldn't
get evaluated properly.


> 
> Anyway, hope  that helps.
> 
> For reference, the difference happens with a  call to finish_return_stmt at
> parser.c:11808 when input_location == 17095968.  We eventually end up in
> cxx_eval_call_expression where the call:
>      constexpr_call **slot
> 	= constexpr_call_table->find_slot (&new_call, INSERT);
> (line 1433) finds a non-empty slot in one case and not in the other. 
> (constexpr_call_table is a deletable hash)