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).
