On 04/12/2016 09:55 AM, Nathan Sidwell wrote:
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.
Right. But richi's comment 22 suggests that we do want to avoid that
sensitivity.
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.
Sounds good.
Jason
