https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594
Nathan Sidwell <nathan at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nathan at gcc dot gnu.org
--- Comment #7 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
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?
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)
