From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21061 invoked by alias); 7 Aug 2012 02:28:05 -0000 Received: (qmail 21050 invoked by uid 22791); 7 Aug 2012 02:28:04 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED 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; Tue, 07 Aug 2012 02:27:50 +0000 From: "aoliva at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/53135] [4.7/4.8 Regression] internal compiler error: in value_format, at dwarf2out.c:8010 Date: Tue, 07 Aug 2012 02:28: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: aoliva at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: aoliva at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.2 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" Content-Transfer-Encoding: quoted-printable 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-08/txt/msg00373.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D53135 --- Comment #7 from Alexandre Oliva 2012-08-07 = 02:26:55 UTC --- Created attachment 27954 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=3D27954 Patch that fixes (or works around?) the problem We have a relatively large expression to represent the outgoing =E2=80=9Cmo= de=E2=80=9D parameter, computed from =E2=80=9Cperms=E2=80=9D, that requires more than 6= 4KiB to represent.=20 block2 is not enough for that. Jakub, is it intentional that we ICE in this case, or is this patch a reasonable change? We successfully output the location expression; surely 64KiB+ expressions might be excessive, but I do= n't think an ICE is the most desirable way to deal with such large expressions = if we build them in the first place.