From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27153 invoked by alias); 2 Jan 2008 13:44:07 -0000 Received: (qmail 27136 invoked by uid 22791); 2 Jan 2008 13:44:06 -0000 X-Spam-Check-By: sourceware.org Received: from server1.sourceware.org (HELO localhost.localdomain) (127.0.0.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 02 Jan 2008 13:37:59 +0000 Subject: [Bug target/31786] [4.1/4.2/4.3 Regression][avr] error: unable to find a register to spill in class 'BASE_POINTER_REGS' In-Reply-To: X-Mailer: Mail::Mailer[v1.74] Net::SMTP[v2.29] X-Bugzilla-Reason: CC References: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "hutchinsonandy at netscape dot net" 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 Date: Wed, 02 Jan 2008 13:44:00 -0000 X-SW-Source: 2008-01/txt/msg00063.txt.bz2 Message-ID: <20080102134400.ZHlh7Zur4ymF6CxRTFqUdWqN2MFX8bKUDazelQCwNbM@z> ------- Comment #13 from hutchinsonandy at netscape dot net 2008-01-02 13:36 ------- Problem occurs because 1 base pointer is used for function pointer and the other is used for frame pointer. (There are only 2). Backend LEGITIMIZE_RELOAD_ADDRESS tells reload to use a base pointer for reload pass of mem(SP+1). This fails. Unfortunately reload does not figure out that it can use frame pointer and gives ICE. (Ironically the frame pointer would be eliminated in this testcase latter) The problem potentially occurs whenever R30,R31 is tied up. (EEPROM macros are other example) Reload calls LEGITIMIZE_RELOAD_ADDRESS when strict address check fails legitimate_address_p on SP+1 - since AVR has no way of indexing from stack pointer. Potential fix is to stop LEGITIMIZE_RELOAD_ADDRESS from telling reload (push_reload) to use BASE_POINTER class. POINTER CLASS is one wider and target macros have pattern to use register 'REG_X' as index (with addition). Alternatively don't suggest any substitution (ie not GOTO WIN) and reload finds answer. The latter solution has been tested and caused ICE in GCC library building as 'REG_X' is not allowable with strict address checking (legitimate_address_p ) - so we get no pattern match ICE for MOVQI (REG_X+1),Rxx. However, backend does contain such patterns. Changing legitimate_address_p to accept REG_X solves problem. In the testcase, the instruction that caused the ICE is eliminated - so the newly allowable pattern is never used. The build ICE caused by first change does indicate that on occasion GCC will really use REG_X as index. Potentially producing sub-optimal code compared with REG_Y or REG_Z. However, the incidence is clearly low and may well be offset by other side effect improvements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786