On 05/09/2016 12:57 PM, Richard Biener wrote:
> does that resolve the issue? If so, this is ok for trunk and branches.
It does. I'll commit the patch to trunk after it finishes regression tests.
Related patches for branches will be prepared after that.
Martin
>From 53c0a7fe057fd2ddd1ab4cea1d5ce4
On Fri, May 6, 2016 at 2:35 PM, Martin Liška wrote:
> On 05/06/2016 12:56 PM, Richard Biener wrote:
>> Hmmm. But this means debug stmt remapping calls
>> remap_dependence_clique which may end up bumping
>> cfun->last_clique and thus may change code generation.
>>
>> So what debug stmts contain ME
On 05/06/2016 12:56 PM, Richard Biener wrote:
> Hmmm. But this means debug stmt remapping calls
> remap_dependence_clique which may end up bumping
> cfun->last_clique and thus may change code generation.
>
> So what debug stmts contain MEM_REFs? If you put an assert
> processing_debug_stmt == 0
On Fri, May 6, 2016 at 12:10 PM, Martin Liška wrote:
> Hi.
>
> I've spotted couple of occurrences of following memory leak seen by valgrind:
>
> malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> operator new(unsigned long) (new_op.cc:50)
> remap_dependence_clique(copy_body_
Hi.
I've spotted couple of occurrences of following memory leak seen by valgrind:
malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
operator new(unsigned long) (new_op.cc:50)
remap_dependence_clique(copy_body_data*, unsigned short) (tree-inline.c:845)
remap_gimple_op_r(tre
