On 04/15/16 10:42, Jason Merrill wrote:
OK, let's go ahead with this.
Thanks for committing Jakub. I've just moved the changelog to cp/ChangeLog
though.
nathan
OK, let's go ahead with this.
Jason
On 04/15/16 05:57, Richard Biener wrote:
On Thu, Apr 14, 2016 at 3:45 PM, Jakub Jelinek wrote:
On Thu, Apr 14, 2016 at 09:43:26AM -0400, Jason Merrill wrote:
On 04/14/2016 09:25 AM, Nathan Sidwell wrote:
On 04/13/16 15:41, Jason Merrill wrote:
The fini_constexpr stuff is OK immediately.
A
On Thu, Apr 14, 2016 at 3:45 PM, Jakub Jelinek wrote:
> On Thu, Apr 14, 2016 at 09:43:26AM -0400, Jason Merrill wrote:
>> On 04/14/2016 09:25 AM, Nathan Sidwell wrote:
>> >On 04/13/16 15:41, Jason Merrill wrote:
>> >
>> >>The fini_constexpr stuff is OK immediately.
>> >
>> >As those two objects ar
On Thu, Apr 14, 2016 at 09:43:26AM -0400, Jason Merrill wrote:
> On 04/14/2016 09:25 AM, Nathan Sidwell wrote:
> >On 04/13/16 15:41, Jason Merrill wrote:
> >
> >>The fini_constexpr stuff is OK immediately.
> >
> >As those two objects are currently GTY((deletable)) I don't think that's
> >necessary.
On 04/14/2016 09:25 AM, Nathan Sidwell wrote:
On 04/13/16 15:41, Jason Merrill wrote:
The fini_constexpr stuff is OK immediately.
As those two objects are currently GTY((deletable)) I don't think that's
necessary. Have I missed something?
True, I suppose it doesn't make much difference.
J
On 04/13/16 15:41, Jason Merrill wrote:
The fini_constexpr stuff is OK immediately.
As those two objects are currently GTY((deletable)) I don't think that's
necessary. Have I missed something?
The rest of the patch is OK if Jakub thinks it should go in, but if his approach
addresses the p
On 04/13/2016 11:54 AM, Nathan Sidwell wrote:
This patch builds from Jason's proto-patch in comment #26. As Jason
discovered, that led to link problems with gt_ggc_mx (tree_node *&) when
building cc1. Making 'hash_map' GC-able caused
gengtype to put the GC-walkers for tree into constexpr.c. No id
This patch builds from Jason's proto-patch in comment #26. As Jason discovered,
that led to link problems with gt_ggc_mx (tree_node *&) when building cc1.
Making 'hash_map' GC-able caused gengtype to put the
GC-walkers for tree into constexpr.c. No idea why. That's also what led me to
add the u
On 04/12/2016 04:58 PM, Nathan Sidwell wrote:
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 ne
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,
On 04/12/2016 11:19 AM, Jakub Jelinek wrote:
On Tue, Apr 12, 2016 at 10:53:22AM -0400, Jason Merrill wrote:
It doesn't seem that dangerous to me. The decls are only used within
constexpr evaluation, they never escape.
The uids can be used in hashing, folding, for the various on the side
table
On 04/12/16 11:19, Jakub Jelinek wrote:
On Tue, Apr 12, 2016 at 10:53:22AM -0400, Jason Merrill wrote:
It doesn't seem that dangerous to me. The decls are only used within
constexpr evaluation, they never escape.
The uids can be used in hashing, folding, for the various on the side
tables (va
On Tue, Apr 12, 2016 at 10:53:22AM -0400, Jason Merrill wrote:
> It doesn't seem that dangerous to me. The decls are only used within
> constexpr evaluation, they never escape.
The uids can be used in hashing, folding, for the various on the side
tables (value-expr, debug-expr, ...).
> >Or perha
On 04/12/2016 10:32 AM, Jakub Jelinek wrote:
On Tue, Apr 12, 2016 at 10:28:39AM -0400, Jason Merrill wrote:
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 wit
On Tue, Apr 12, 2016 at 10:28:39AM -0400, Jason Merrill wrote:
> >>>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
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?
On Tue, Apr 12, 2016 at 09:55:47AM -0400, 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, IIU
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
On 04/11/2016 03:42 PM, Nathan Sidwell wrote:
This proto patch addresses 70594, where the constexpr machinery causes
differences in -fcompare-debug checking. I'm looking for initial
comments about the approach this patch is taking.
As described in the comments of
https://gcc.gnu.org/bugzilla/sh
On Mon, Apr 11, 2016 at 3:42 PM, Nathan Sidwell wrote:
> This proto patch addresses 70594, where the constexpr machinery causes
> differences in -fcompare-debug checking. I'm looking for initial comments
> about the approach this patch is taking.
>
> As described in the comments of
> https://gcc.
This proto patch addresses 70594, where the constexpr machinery causes
differences in -fcompare-debug checking. I'm looking for initial comments about
the approach this patch is taking.
As described in the comments of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 the change is being cau
22 matches
Mail list logo
