From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14974 invoked by alias); 16 Jan 2005 07:17:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 14956 invoked by alias); 16 Jan 2005 07:16:57 -0000 Date: Sun, 16 Jan 2005 07:17:00 -0000 Message-ID: <20050116071657.14954.qmail@sourceware.org> From: "schlie at comcast dot net" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20041019202143.18065.schlie@comcast.net> References: <20041019202143.18065.schlie@comcast.net> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug tree-optimization/18065] usual arithmetic conversion not applying correctly X-Bugzilla-Reason: CC X-SW-Source: 2005-01/txt/msg02079.txt.bz2 List-Id: ------- Additional Comments From schlie at comcast dot net 2005-01-16 07:16 ------- Subject: Re: usual arithmetic conversion not applying correctly Wonder if this PR could still be considered a missed optimization, as the present logic which determines if an / or % expression's operands may be shortened, misses the case where if the lhs operand is a constant, it may be verified as not being INT_MIN; as if it's not, then it's impossible for the operation to overflow, i.e. INT_MIN / -1 => INT_MAX+1, therefore may be shortened. As noted as being absent in it's comment on shortening: /* Although it would be tempting to shorten always here, that loses on some targets, since the modulo instruction is undefined if the quotient can't be represented in the computation mode. We shorten only if unsigned or if dividing by something we know != -1. */ > From: pinskia at gcc dot gnu dot org > Subject: [Bug tree-optimization/18065] usual arithmetic conversion not > applying correctly > > -- > What |Removed |Added > ---------------------------------------------------------------------------- > Severity|normal |enhancement > Priority|P1 |P3 > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065