[Bug c/108941] Error: operand type mismatch for `shr' with binutils master

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to jbeulich from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > GCC doesn't even have that information at all, at the RTL level it doesn't
> > know
> > if it was signed or unsigned.
> > All it has is the constraint and operand for it, like (reg:QI 126) or
> > (const_int -1).
> > As I said earlier, constants are always sign-extended from their mode.
> > One could e.g. have during expansion (set (reg:QI 126) (const_int -1))
> > and later on asm_operands with "ic" and (reg:QI 126).  Same assignment for
> > int8_t x = -1 or int8_t x = 255 or uint8_t x = -1 or uint8_t x = 255, at
> > GIMPLE one can differentiate that based on types, at RTL one has just mode.
> 
> While for int8_t x = -1 or int8_t x = 255 I can see that the result is as
> described, for uint8_t x = -1 or uint8_t x = 255 (or, as in the example, a
> constant the was cast to an unsigned 8-bit type) why is it not (const int
> 255)?

Because RTL doesn't have the notion of signed/unsigned types, only modes (which
don't have a sign).  For many operations there is no difference in how they
behave with signed and unsigned values, say PLUS works the same.  And where it
matters, the signed vs. unsigned is encoded in the code of the operation (there
is say arithmetic right shift and logical right shift).  (const_int 255) is
invalid where 8-bit quantity is required.