From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-21624-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 20421 invoked by alias); 9 Sep 2002 10:56:45 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 20399 invoked by uid 61); 9 Sep 2002 10:56:44 -0000
Date: Mon, 09 Sep 2002 03:56:00 -0000
Message-ID: <20020909105644.20398.qmail@sources.redhat.com>
To: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nickc@redhat.com,
  nobody@gcc.gnu.org, pb@nexus.co.uk, rearnsha@arm.com
From: rearnsha@gcc.gnu.org
Reply-To: rearnsha@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
  nickc@redhat.com, nobody@gcc.gnu.org, pb@nexus.co.uk, rearnsha@arm.com,
  gcc-gnats@gcc.gnu.org
Subject: Re: target/7856: [arm] invalid offset in constant pool reference
X-SW-Source: 2002-09/txt/msg00130.txt.bz2
List-Id: <gcc-prs.sourceware.org>

Synopsis: [arm] invalid offset in constant pool reference

State-Changed-From-To: open->analyzed
State-Changed-By: rearnsha
State-Changed-When: Mon Sep  9 03:56:43 2002
State-Changed-Why:
    Confirmed as a bug.
    
    The problem comes about due to a change that Nick made to 
    try to improve the performance of prologue and epilogue code.
    His change means that if the link register is not clobbered then
    it is never saved on the stack, even if other call-saved registers
    need to be saved.  The consequence of this is that we 
    sometimes end up generating 2-instruction return sequences
    when we previously only generated a single instruction.
    
    Although at first sight this appears to be faster, it is not 
    necessarily the best soloution, particularly when the return
    is conditional, since we end up making the conditional
    sequence longer.
    
    The particular consequence of this change is that the length of the 'return' and 'conditional-return' instructions needs to take
    into account this longer sequence if the constant spilling code
    is to do its job correctly.
    
    However, I'm not yet convinced that Nick's change is for the
    best overall.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7856