On 11/14/14 03:34, Richard Biener wrote:
Well - we do have that scary TODO_do_not_ggc_collect. It would be
nice to be able to call protect_gc () from ira.c and unprotect_gc ()
from the reload/lra pass and get rid of that TODO.
Yea, can't argue with that.
And yes, a ggc_collect () should be
On Fri, Nov 14, 2014 at 2:19 AM, Jeff Law wrote:
> On 11/13/14 08:28, David Malcolm wrote:
>
It was pointed out to me on IRC that I could instead use RAII for this,
so here's an alternative version of the patch that puts it in a class,
so that you can put:
auto_assert_
On 11/13/14 08:28, David Malcolm wrote:
It was pointed out to me on IRC that I could instead use RAII for this,
so here's an alternative version of the patch that puts it in a class,
so that you can put:
auto_assert_no_gc no_gc_here;
into a scope to get the assertion failure if someone use
On Thu, 2014-11-13 at 11:22 +0100, Richard Biener wrote:
> On Wed, Nov 12, 2014 at 11:04 PM, David Malcolm wrote:
> > On Wed, 2014-11-12 at 13:16 -0500, David Malcolm wrote:
> >> We make assumptions in the codebase about when the GC can run, and when
> >> it can't (e.g. within numerous passes) but
On Wed, Nov 12, 2014 at 11:04 PM, David Malcolm wrote:
> On Wed, 2014-11-12 at 13:16 -0500, David Malcolm wrote:
>> We make assumptions in the codebase about when the GC can run, and when
>> it can't (e.g. within numerous passes) but these aren't captured in a way
>> that's verifiable.
>>
>> This
On Wed, 2014-11-12 at 13:16 -0500, David Malcolm wrote:
> We make assumptions in the codebase about when the GC can run, and when
> it can't (e.g. within numerous passes) but these aren't captured in a way
> that's verifiable.
>
> This patch introduces macros GGC_{BEGIN|END}_ASSERT_NO_COLLECTIONS
