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.
