From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14061 invoked by alias); 4 Jan 2012 11:26:13 -0000 Received: (qmail 14037 invoked by uid 22791); 4 Jan 2012 11:26:12 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 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:25:59 +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:26: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: CC 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/msg00359.txt.bz2 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.