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
On Mar 18, 2014, Jakub Jelinek ja...@redhat.com 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
On Sat, Mar 15, 2014 at 5:09 AM, Mike Stump mikest...@comcast.net wrote:
On Mar 14, 2014, at 7:45 PM, Alexandre Oliva aol...@redhat.com 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
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.
On Mar 14, 2014, at 7:45 PM, Alexandre Oliva aol...@redhat.com 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
