On Mar 18, 2014, Jakub Jelinek wrote:
>> --- a/gcc/function.c
>> +++ b/gcc/function.c
>> @@ -4498,6 +4498,8 @@ allocate_struct_function (tree fndecl, bool abstract_p)
>>
>> cfun = ggc_alloc_cleared_function ();
>>
>> + SET_BUILD_DEBUG_STMTS (cfun, flag_var_tracking_assignments);
> Dunno how t
On Fri, Mar 14, 2014 at 11:45:48PM -0300, Alexandre Oliva wrote:
> This bug report had various testcases that had to do with full loop
> unrolling with non-automatic iterators and fixed boundaries, which
> resulted in duplicating debug stmts in the loop for each iteration. In
> some cases, the res
On Sat, Mar 15, 2014 at 5:09 AM, Mike Stump wrote:
> On Mar 14, 2014, at 7:45 PM, Alexandre Oliva wrote:
>> In some cases, the resulting executable code is none, but the debug stmts
>> add up to millions.
>
> I'd like to think there is a better theoretic answer to the specific
> problem... trim
On Mar 14, 2014, at 7:45 PM, Alexandre Oliva wrote:
> In some cases, the resulting executable code is none, but the debug stmts
> add up to millions.
I’d like to think there is a better theoretic answer to the specific problem…
trimming random debug info I think just invites a bad experience wh
This bug report had various testcases that had to do with full loop
unrolling with non-automatic iterators and fixed boundaries, which
resulted in duplicating debug stmts in the loop for each iteration. In
some cases, the resulting executable code is none, but the debug stmts
add up to millions.
