From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12993 invoked by alias); 20 Jul 2011 20:24:11 -0000 Received: (qmail 12981 invoked by uid 22791); 20 Jul 2011 20:24:10 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_XF X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 Jul 2011 20:23:49 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p6KKNgKZ028092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Jul 2011 16:23:42 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (tyan-ft48-01.lab.bos.redhat.com [10.16.42.4]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p6KKNf6F001232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2011 16:23:41 -0400 Received: from tyan-ft48-01.lab.bos.redhat.com (localhost.localdomain [127.0.0.1]) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4) with ESMTP id p6KKNeIc004594; Wed, 20 Jul 2011 22:23:40 +0200 Received: (from jakub@localhost) by tyan-ft48-01.lab.bos.redhat.com (8.14.4/8.14.4/Submit) id p6KKNdjl004592; Wed, 20 Jul 2011 22:23:39 +0200 Date: Wed, 20 Jul 2011 20:55:00 -0000 From: Jakub Jelinek To: Michael Eager Cc: Alexandre Oliva , Bernd Schmidt , gcc-patches@gcc.gnu.org Subject: Re: introduce --param max-vartrack-expr-depth Message-ID: <20110720202339.GJ2687@tyan-ft48-01.lab.bos.redhat.com> Reply-To: Jakub Jelinek References: <4DE3784F.6050201@codesourcery.com> <4E27358C.7050109@eagerm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E27358C.7050109@eagerm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg01682.txt.bz2 On Wed, Jul 20, 2011 at 01:07:40PM -0700, Michael Eager wrote: > I've run into a problem with this change when building microblaze-xilinx-elf. > > When compiling _divdi3.o, cselib_expand_value_rtx_1 returns a huge rtx > tree for variable _r1 when max_depth is greater than 17. If -g is > specified, this later results in attempting to generate a DWARF location > list much larger than the 0xffff size limit, resulting in an assert failure. I think Alex is working on a patch which will hopefully improve it. In 4.6-RH in the mean time we are defaulting max-vartrack-expr-depth to 12 instead, perhaps that would be better than 10. As for the 0xffff size limit, I'd say we should handle it instead of asserting, e.g. if the size is 64K or more, we could emit there a single DW_OP_call4 + DW_TAG_dwarf_procedure that would contain it. Or just drop the range on the floor, still better than ICE. > 2011-07-20 Michael Eager > > * params.def (PARAM_MAX_VARTRACK_EXPR_DEPTH): Default to 10. > > Index: gcc/params.def > =================================================================== > --- gcc/params.def (revision 176533) > +++ gcc/params.def (working copy) > @@ -845,7 +845,7 @@ > DEFPARAM (PARAM_MAX_VARTRACK_EXPR_DEPTH, > "max-vartrack-expr-depth", > "Max. recursion depth for expanding var tracking expressions", > - 20, 0, 0) > + 10, 0, 0) Jakub