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 09:55:47 -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>
Most of the conversation appears to be happening in bugzilla ...
On 04/12/16 09:18, Jason Merrill wrote:
I still think that -fcompare-debug being sensitive to exact DECL_UID is the real
bug here.
Plausible, IIUC Jakub's suggested patches for that?
If we go that way, I think most of the below is moot, modulo DECL_UIDs being
GC-sensitive at all.
1) I think this approach is not globally best. We're inventing another
memory-usage related heuristic, rather than relying on the already
available GC machinery. That's why I've gone with a hard coded value
for now, rather than add a new user-frobable param. The right solution
is to stop generating new DECL_UIDs when copying fns for constexpr
evaluation. IIUC the UID is being used to map decls to values. I don't
see why we can't just use the (copied) DECL's address as a key to find
its associated value (but I've not investigated that approach).
The mapping is already from the decl's address.
Oh, good. that's not what comment #9 claimed, and I didn't check. It does look
like a straight forward tree->tree mapper now I look.
It sounds like stopping copy_fn allocating new UIDs should be fine, and will
then stop them being GC-sensitive.
nathan