From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6900 invoked by alias); 4 Jan 2012 11:05:12 -0000 Received: (qmail 6888 invoked by uid 22791); 4 Jan 2012 11:05:10 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_TX X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Jan 2012 11:04:58 +0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/51695] [4.7 Regression] ICE while compiling argyllcms package Date: Wed, 04 Jan 2012 11:05:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-01/txt/msg00356.txt.bz2 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.c 2012-01-03 16:22:48.794866121 +0100 +++ gcc/dwarf2out.c 2012-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 > 0xffff) + 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 <= 0xffff); 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 [0xffffffffa398655d])) (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.