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

["jbeulich at suse dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #16 from jbeulich at suse dot com ---
(In reply to Jakub Jelinek from comment #15)
> Above you're mixing a 32-bit argument with 8-bit argument in an instruction
> which
> expects probably 2 32-bit arguments or at least both arguments with the same
> width.
> Just try to pass 2 variables to it and use "ri" and you'll see assembler
> errors,
> add %dl, %eax and the like.

Of course, and I did say the example was over-simplified. If it helps, consider
(as also indicated) invoking a macro instead, which then inspects the operands
and decides what insn to produce. This could be particularly interesting with
the .insn that I'm in the process of preparing to add to x86 gas, where one
would then inspect arguments in order to select a suitable major opcode. Since
x86 has different possible encodings for "add immediate", the wrongly
represented value would then lead to silent bad code generation. And btw - what
"size" to assign to e.g. a sign-extended 8-bit immediate is at least ambiguous.

I can only repeat: Unless the anomaly is properly called out in non-internal
documentation, I continue to think there's a bug here. And the reference to
Clang getting it right, which you simply put off, isn't entirely meaningless
imo (I agree we're talking about a GNU extension here, but that doesn't imply
only GNU tools can get it right).