From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-98191-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 30762 invoked by alias); 4 Jun 2004 16:41:16 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 30715 invoked by uid 48); 4 Jun 2004 16:41:13 -0000
Date: Fri, 04 Jun 2004 16:41:00 -0000
From: "ajrobb at bigfoot dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Message-ID: <20040604164108.15823.ajrobb@bigfoot.com>
Reply-To: gcc-bugzilla@gcc.gnu.org
Subject: [Bug c/15823] New: optimise >>> style calculation
X-Bugzilla-Reason: CC
X-SW-Source: 2004-06/txt/msg00483.txt.bz2
List-Id: <gcc-bugs.sourceware.org>

The C code fragment (i & (~0<<n))/(1<<n) is equivalent to Java's i>>>n 
arithmetic shift (at least for n < sizeof(i)*CHAR_BIT). 
 
There are two problems: 
 
1) if n is not a manifest constant, i/(1<<n) uses divide. 
 
2) Even when n is a constant, say 2: 
 
(i & ~3)/4 
 
still does not compile to a single SAR (x86) it still checks the sign and adds 
3 if negative.

-- 
           Summary: optimise >>> style calculation
           Product: gcc
           Version: 3.3.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ajrobb at bigfoot dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i586-suse-linux
  GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15823