This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] c++/70594 debug info differences
- From: Nathan Sidwell <nathan at acm dot org>
- To: Jason Merrill <jason at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, Patrick Palka <patrick at parcs dot ath dot cx>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Guenther <richard dot guenther at gmail dot com>
- Date: Tue, 12 Apr 2016 16:58:56 -0400
- Subject: Re: [PATCH] c++/70594 debug info differences
- Authentication-results: sourceware.org; auth=none
- References: <570BFE33 dot 4030305 at acm dot org> <570CF588 dot 8020006 at redhat dot com> <570CFE63 dot 2010209 at acm dot org> <570D0617 dot 6090201 at redhat dot com>
Well, I had a patch all ready, but when writing it up, I discovered the logic
behind comment #26 is wrong. Specifically, Jason's proto-patch makes the
fn_copy_table GCable, but keeps the constexpr_call_table GC-deletable. The
logic is that if we need to recreate a particular constexpr call, we'll have a
body available so not need to do another copy. But consider a constexpr such as:
constexpr int Foo (int i) { return i ? Foo (i - 1) : 0; }
Then the following evaluations:
Foo (0)
<possible GC>
Foo (1)
If the GC does not happen, we'll have cached the evaluation of 'Foo(0)', and so
not need to reevaluate it during the 'Foo(1)' call. The evaluation of 'Foo(1)'
will use the single cached body of Foo for it's own evaluation, so no additional
cloning will happen.
However, if the GC does happen, we'll need to evaluate 'Foo(0)' again, but
there'll be no cached body of Foo available (it being in use for 'Foo(1)'). So
we will observe a UID change.
I think that means the constexpr_call_table must be preserved too. Something
along the lines of the size checking I posted yesterday? (but with the GTY stuff
done better).
nathan