From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7762 invoked by alias); 15 Jun 2011 21:58:24 -0000 Received: (qmail 7753 invoked by uid 22791); 15 Jun 2011 21:58:24 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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, 15 Jun 2011 21:58:06 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p5FLw3Im022034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Jun 2011 17:58:03 -0400 Received: from anchor.twiddle.net (vpn-238-54.phx2.redhat.com [10.3.238.54]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p5FLw2sf017579; Wed, 15 Jun 2011 17:58:02 -0400 Message-ID: <4DF92AEA.4000906@redhat.com> Date: Wed, 15 Jun 2011 22:20:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10 MIME-Version: 1.0 To: Georg-Johann Lay CC: Denis Chertykov , gcc-patches@gcc.gnu.org, Anatoly Sokolov , "Eric B. Weddington" Subject: Re: [Patch, AVR]: Fix PR46779 References: <4DF0FAB5.6070704@gjlay.de> <4DF11D20.4030907@gjlay.de> <4DF1ED76.4030507@gjlay.de> <4DF650B7.3030705@gjlay.de> <4DF73490.2080709@gjlay.de> <4DF7D2B5.1090708@gjlay.de> <4DF8ED42.1030706@redhat.com> <4DF918A9.4070003@gjlay.de> In-Reply-To: <4DF918A9.4070003@gjlay.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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-06/txt/msg01183.txt.bz2 On 06/15/2011 01:40 PM, Georg-Johann Lay wrote: > But I still wonder what's the very problem. Any architecture has > limited reg+const addressing and limited number of address > registers. I definetely saw architectures run out of registers and > reload manages to access stack beyond reg+maxoff without any hacks > and clear and straight forward backend. Well, this is probably the only architecture that has *no* non-fixed, call-saved base registers. Indeed, I can work around this particular crash by either hacking Z to be call-saved, or hacking the frame pointer to not be required. The former of course changes the abi, and the second produces awful code due to too many copies from the stack pointer. So neither option is "preferred". r~