------- Additional Comments From schlie at comcast dot net 2004-10-20 19:33 ------- Subject: Re: usual arithmetic conversion not applying correctly
Maybe the confusion is that you're not recognizing that: char, short, int, long, long long, are all integer types, with different storage formats. As opposed to enum or bit-field for example which should likely be converted to an "integer type" with ideally the smallest and/or most efficient representation specified for the machine, prior to an "integer" oriented operation being performed. ??? -paul- > From: Paul Schlie <[EMAIL PROTECTED]> > Date: Wed, 20 Oct 2004 15:14:08 -0400 > To: <[EMAIL PROTECTED]> > Subject: Re: [Bug c/18065] usual arithmetic conversion not applying correctly > > Please read rule 1: > > "If both operands have the same type, then no further conversion is > needed." (no promotion to int is specified or implied as being required) > > Seems plain enough to me, what makes you think that: > > char + char => int + int ? > short + short => int + int ? > > That would imply, QI mode (and HI mode typical of shorts on 32 bit machines) > rtl instruction definitions are meaningless which isn't the case; as their > definition defines the char and short operand rtl operator -> code > transformation. > > The front end has no business promoting all char and short arithmetic operands > to ints, and in fact it doesn't; so am not sure what your thinking? > > -paul- > >> From: pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> >> Reply-To: <[EMAIL PROTECTED]> >> Date: 20 Oct 2004 18:50:01 -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 >> 18:50 ------- >> From C99 >> (6.5.5/3): The usual arithmetic conversions are performed on the operands. >> >> 6.3.1.8 Usual arithmetic conversions >> Otherwise, the integer promotions are performed on both operands. Then the >> following rules are >> applied to the promoted operands: If both operands have the same type, then >> no >> further conversion is >> needed. Otherwise, if both operands have signed integer types or both have >> unsigned integer types, the >> operand with the type of lesser integer conversion rank is converted to the >> type of the operand with >> greater rank. Otherwise, if the operand that has unsigned integer type has >> rank greater or equal to the >> rank of the type of the other operand, then the operand with signed integer >> type is converted to the >> type of the operand with unsigned integer type. Otherwise, if the type of the >> operand with signed >> integer type can represent all of the values of the type of the operand with >> unsigned integer type, then >> the operand with unsigned integer type is converted to the type of the >> operand >> with signed integer >> type. Otherwise, both operands are converted to the unsigned integer type >> corresponding to the type of >> the operand with signed integer type. >> >> This is still not wrong code as signed char signed extended to int is still >> the same number but this is >> not a target problem but a front-end problem now. >> >> To make sure that I read the statement correctly from the standard, it says >> if >> the types are the same >> there is no need to promote the value at all. >> >> -- >> What |Removed |Added >> ---------------------------------------------------------------------------- >> Severity|minor |normal >> Component|target |c >> Summary|not using qi version of |usual arithmetic conversion >> |divmod |not applying correctly >> >> >> 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
