From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14905 invoked by alias); 25 Sep 2002 20:19:13 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 14898 invoked from network); 25 Sep 2002 20:19:12 -0000 Received: from unknown (HELO pizda.ninka.net) (216.101.162.242) by sources.redhat.com with SMTP; 25 Sep 2002 20:19:12 -0000 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id NAA17579; Wed, 25 Sep 2002 13:08:54 -0700 Date: Wed, 25 Sep 2002 13:43:00 -0000 Message-Id: <20020925.130854.01705734.davem@redhat.com> To: mark@codesourcery.com Cc: gcc@gcc.gnu.org Subject: Re: Release schedule From: "David S. Miller" In-Reply-To: <23100000.1032978530@warlock.codesourcery.com> References: <23100000.1032978530@warlock.codesourcery.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg01012.txt.bz2 target/7842 is a very fundamental flaw in the sparc backend, the test case example in the gnats entry is just the tip of the iceberg. In v8plus and arch64 mode we provide all of the SImode patterns, and GCC thinks that all of them clear out the upper 32-bits of the result in the destination (only 32-bit shift right actually does). Thus combine eliminates a lot of zero/sign extend operation, in places where it absolutely cannot do so legally. One solution would be to not provide the SImode variants in arch64 mode, but this is not a solution because: 1) It doesn't handle the v8plus case at all, which is the instance being used by the target/7842 test case 2) It would require a complete verification and potential rewrite of the compare stuff for arch64 if we don't provide the SImode patterns. So a simpler more direct fix is needed to cure this. I've tried to work on this off and on, but currently I'm not able to allot the amount of time to GCC that I would like so it's unlikely that I'll be able to fix this in time for 3.2.1 Nevertheless it is a very important bug to have fixed.