[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695 --- Comment #6 from Jakub Jelinek 2012-01-04 19:58:07 UTC --- Author: jakub Date: Wed Jan 4 19:58:03 2012 New Revision: 182886 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182886 Log: PR debug/51695 * dwarf2out.c (output_loc_list): For now drop >= 64KB expressions in .debug_loc on the floor. * gcc.dg/pr51695.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr51695.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695 --- Comment #5 from Jan Kratochvil 2012-01-04 14:20:29 UTC --- (In reply to comment #4) > they could have unwanted > side-effects (reading uninitialized memory, division by zero, producing NaNs > etc.) that the debugger might complain about loudly. GDB will complain. > create a DW_TAG_dwarf_procedure for them and just replace those subexpressions > with DW_OP_call* to that procedure. DW_OP_call{2,4} is supported by GDB now. DW_TAG_dwarf_procedure is unsupported now but it looks like a "oneliner" patch, ping me for DW_TAG_dwarf_procedure implementation, please.
[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695 Richard Guenther changed: What|Removed |Added Priority|P3 |P1
[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695 Jakub Jelinek changed: What|Removed |Added CC||jan.kratochvil at redhat ||dot com --- Comment #4 from Jakub Jelinek 2012-01-04 11:25:57 UTC --- One problem with such temporaries approach would be that if the temporaries are in the whole expression evaluated only conditionally, they could have unwanted side-effects (reading uninitialized memory, division by zero, producing NaNs etc.) that the debugger might complain about loudly. Say if the expression is (if_then_else (r1 < 56) (temp1) (const_int 0)) where temp1 is (mem (foo + r1)) or similar, if we evaluate it upfront, the debugger might complain. Another alternative would be (for a dwarf2out.c solution, so the compile time memory issue would be still there) when we'd be finalizing all the DWARF expressions in the CU, we'd somehow hash the larger subexpressions where it might be beneficial and if they are long enough and occur at least twice, create a DW_TAG_dwarf_procedure for them and just replace those subexpressions with DW_OP_call* to that procedure.
[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695 --- Comment #3 from Jakub Jelinek 2012-01-04 11:04:41 UTC --- We can always work around this as in (completely untested): --- gcc/dwarf2out.c2012-01-03 16:22:48.794866121 +0100 +++ gcc/dwarf2out.c2012-01-04 11:50:30.516022278 +0100 @@ -8166,6 +8166,13 @@ output_loc_list (dw_loc_list_ref list_he /* Don't output an entry that starts and ends at the same address. */ if (strcmp (curr->begin, curr->end) == 0 && !curr->force) continue; + size = size_of_locs (curr->expr); + /* If the expression is too large, drop it on the floor. We could + perhaps put it into DW_TAG_dwarf_procedure and refer to that + in the expression, but >= 64KB expressions for a single value + in a single range are unlikely very useful. */ + if (size > 0x) +continue; if (!have_multiple_function_sections) { dw2_asm_output_delta (DWARF2_ADDR_SIZE, curr->begin, curr->section, @@ -8184,7 +8191,6 @@ output_loc_list (dw_loc_list_ref list_he "Location list end address (%s)", list_head->ll_symbol); } - size = size_of_locs (curr->expr); /* Output the block length for this list of location operations. */ gcc_assert (size <= 0x); But it would be nice to a) find out how can we limit the excessive expression sizes still during var-tracking, because it might consume lots of compile time memory b) if we can't do anything smarter at least in cases like PR51695 where the expression is so huge just because it keeps computing the same values again and again and again. If we remembered we have computed some VALUE (with a non-trivial expression of more than say 16 rtxes in it), we could represent it as tmpforvalueXXX = the_rtx, and then just use the temporary in all places. In the DWARF expression it would mean we'd compute (all the temporaries) first and keep them pushed into the DWARF stack, then once all those are computed we'd just DW_OP_picked the values we want (as many times as needed). So, e.g. in the pr51695 case, we'd have a temporary for: (if_then_else:SI (lt (mem/c/i:SI (symbol_ref:DI ("v") [flags 0x2] ) [2 v+0 S4 A32]) (const_int 0 [0])) (xor:SI (ashift:SI (mem/c/i:SI (symbol_ref:DI ("v") [flags 0x2] ) [2 v+0 S4 A32]) (const_int 1 [0x1])) (const_int -1550293667 [0xa398655d])) (ashift:SI (mem/c/i:SI (symbol_ref:DI ("v") [flags 0x2] ) [2 v+0 S4 A32]) (const_int 1 [0x1]))) expression and use it in all the places where it is used (in that testcase this is used over 2000 times), then perhaps some larger expression that uses these many times would be again a temporary, etc. and here we could end up with a DWARF expression of only few dozens of bytes.
[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-30 Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski 2011-12-30 23:32:06 UTC --- (note 218 174 131 2 (var_location o (and:SI (reg:SI 1 dx [orig:90 iftmp.0 ] [90]) (const_int 65535 [0x]))) NOTE_INSN_VAR_LOCATION) (insn:TI 131 218 219 2 (parallel [ (set (reg:SI 2 cx [135]) (and:SI (reg:SI 1 dx [orig:90 iftmp.0 ] [90]) (const_int 65535 [0x]))) (clobber (reg:CC 17 flags)) ]) t.c:23 380 {*andsi_1} (expr_list:REG_UNUSED (reg:CC 17 flags) (nil))) (note 219 131 116 2 (var_location o (and:SI I think that last var_location should just be like the others and use cx instead. Confirmed.
[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695 --- Comment #1 from Jakub Jelinek 2011-12-28 11:35:23 UTC --- The NOTE_INSN_VAR_LOCATION argument for variable o is extremely huge in this case and we hit the 64KB limit on .debug_loc expressions.
[Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51695 Jakub Jelinek changed: What|Removed |Added Component|tree-optimization |debug Target Milestone|--- |4.7.0