------- Additional Comments From schlie at comcast dot net 2004-10-21 01:28 ------- Subject: Re: usual arithmetic conversion not applying correctly
Andrew, So regardless of the all other things, it seems minimally clear that the promotion code as it stands now should allow the required result type to be shortened to the size and type of the modulus operand for modulus operations; and to the size and type of the dividend operand if the divisor is unsigned, and the required result precision promoted to the next larger signed type otherwise (although not strictly required if the true destination's precision requirement is less). Which should address the short term problem associated with type promotion being done by the front end. -paul- > From: Paul Schlie <[EMAIL PROTECTED]> > Date: Wed, 20 Oct 2004 17:19:24 -0400 > To: <[EMAIL PROTECTED]> > Subject: Re: [Bug c/18065] 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 <[EMAIL PROTECTED]> >> Reply-To: <[EMAIL PROTECTED]> >> Date: 20 Oct 2004 19:29:13 -0000 >> To: <[EMAIL PROTECTED]> >> 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
