From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4764 invoked by alias); 20 Oct 2004 21:19:42 -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 4755 invoked by alias); 20 Oct 2004 21:19:40 -0000 Date: Wed, 20 Oct 2004 21:19:00 -0000 Message-ID: <20041020211940.4754.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 c/18065] usual arithmetic conversion not applying correctly X-Bugzilla-Reason: CC X-SW-Source: 2004-10/txt/msg02700.txt.bz2 List-Id: ------- Additional Comments From schlie at comcast dot net 2004-10-20 21:19 ------- Subject: Re: usual arithmetic conversion not applying correctly Andrew, Yes, and with respect to / and % operations: - the modulo/reminder result can always be represented in the same type and size as its divisor/modulus operand, regardless of the dividend's type and size. - the quotient result can always be represented in the same type and size as it's dividend, if it's divisor/modulus operand is unsigned, otherwise ideally to be promoted to it's next larger signed type to preserve accuracy if useful, but typically irrelevant, as operator result precision is in most practical circumstances determined by the precision of the result's need, therefore in typical cases like int = int / int no value is derived from pretending to preserve idealized accuracy, therefore CPU's typically implement instructions to yield the equivalent results that would have been attained if the precision were maintained, and then simply truncated when assigned to it's destination type for typical integer operations but mark an under or overflow flag, just as int = int + int; would overflow; therefore for all practical purposes, integer operands should never be promoted beyond their need, nor should operation precision be required beyond it's result's need. (and just to double check, this needs to get fixed on 3.4.3 too, which I honestly suspect is related to the rtl interpretation, as other QI mode instruction specifications are properly matched as expected.) (also it's likely that these type of problems predominantly express themselves on small target machines, as on larger 32/64 bit machines, operations physically occur on correspondingly wide cpu's, therefore don't enable inappropriate operand promotion errors to be easily observable.) -paul- > From: pinskia at gcc dot gnu dot org > Reply-To: > Date: 20 Oct 2004 19:29:13 -0000 > To: > Subject: [Bug c/18065] usual arithmetic conversion not applying correctly > > > ------- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 > 19:29 ------- > And the reason why we don't shoten back to signed char % signed char: > > /* 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. */ > > So maybe this is correct. > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065