[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 jakub at gcc dot gnu.org 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] var_decl
0x7 f431dcea140 v) [2 v+0 S4 A32]) (const_int 0 [0]))
(xor:SI (ashift:SI (mem/c/i:SI (symbol_ref:DI (v) [flags 0x2] var_decl
0x7f431dcea140 v) [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] var_decl
0x7f431dcea140 v) [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 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jan.kratochvil at redhat ||dot com --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 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 Richard Guenther rguenth at gcc dot gnu.org 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
--- Comment #5 from Jan Kratochvil jan.kratochvil at redhat dot com
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 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 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=gccview=revrev=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
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-12-30
Ever Confirmed|0 |1
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 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 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Component|tree-optimization |debug Target Milestone|--- |4.7.0
[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 jakub at gcc dot gnu.org 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.
