Created attachment 14942 [details] Generated assembly This is a "regression" from: commit c34d1cc9200ae24dc7572aaf77d80276c0490e9b Author: Jan Beulich <jbeulich@suse.com> Date: Fri Feb 24 13:56:57 2023 +0100 x86: restrict insn templates accepting negative 8-bit immediates The code that fails to assemble comes from inline assembly from ffmpeg, and compiled with GCC. I'm going to attach both the preprocessed C source, and the generated assembly. The failing instructions look like: shrl $-8, %eax which, considering the commit, it not too surprising. The corresponding code in C looks like: static inline uint32_t NEG_USR32(uint32_t a, int8_t s){ __asm__ ("shrl %1, %0\n\t" : "+r" (a) : "ic" ((uint8_t)(-s)) ); return a; } The question is open whether this is a problem in GCC, GAS, or ffmpeg. One could argue in any direction, I guess. I'm starting with GAS, since it's a change there that started this.
Created attachment 14943 [details] Preprocessed C source
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108941. The cast in (uint8_t)(-s) isn't honored by gcc when s can be determined to be a plain number, making it emit a negative value. Negative shift counts of course make no sense (on x86 at least). See the description of the referenced binutils patch as to the resulting misbehavior for RCL and RCR. For SHL/SHR etc the behavior would still be correct, but (dis)allowing negative shift counts there is a matter of consistency. I won't mark this "invalid" right away, to allow for discussion to happen here that should have happened on the patch submission (if need be).
Also came here from `ffmpeg` build failure. I would suggest improving error message a bit on `gas` side as it's very cryptic otherwise: $ cat a.s .text foo: shrl $-10, %eax $ gcc -c a.s a.s: Assembler messages: a.s:3: Error: operand type mismatch for `shr'