[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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
How does that look like a gcc bug?  It is either a binutils bug for not
accepting it anymore, or ffmpeg-4 bug for relying on the negative shifts.
GCC inline asm has always worked like that, the operand is 8-bit and in GCC
constants are always sign-extended.
If you try just
static inline unsigned int
foo (unsigned int a, signed char s)
{
  asm volatile ("# %1" : "+r" (a) : "ic" ((unsigned char) -s));
  return a;
} 

void
bar (void)
{
  foo (0, 1);
}
I get the same behavior of # $-1 with trunk or GCC 3.2.
In the assembly, if you have a spot which accepts 8-bit quantity, one shouldn't
care if it is signed or unsigned.  If you care about the upper bits, you
shouldn't pretend the operand is 8-bit but say 32-bit by adding (int) cast to
it.