This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: mov{s,z}{b,w,l} suffix guessing

>>> On 28.06.16 at 16:44, <> wrote:
> On Tue, Jun 28, 2016 at 7:00 AM, Jan Beulich <> wrote:
>> H.J.,
>> i386-opc.tbl has "interesting" comments around these, and the
>> assembler as a result provides inconsistent behavior: For one
>> because of the recognition of the suffix-less movzb (as the
>> only exception). And of course with both instruction groups
>> therefore being different from all other instructions with
>> register operands. So the question is: Are these inconsistencies
>> really intended, or wouldn't it be better to enhance things so
>> that at least the final suffix bytes on these two groups won't
>> be required anymore? (Clearly when both operands are
>> registers, one could even aim at making the second from last
>> suffix byte optional too.)
>> And if the current (sorry) state is intentional, shouldn't use of
>> suffix-less movzb at least get warned about, to pave a road
>> towards removing that exception?
> Please open a bug with all these issues you found.  We should
> investigate them.  If changing them doesn't introduce any test
> failures and gcc/glibc/kernel have no issues, we should fix it.

I've submitted the adjustment for movz [1]. I've also got the then
trivial movs adjustment ready, but it depends on both that one
(context wise) and the fix for Intel mode movsd operand checking
(functionality wise) [2], so I'll submit that one once those two have
gone in (if they're allowed to), or another solution to the problem
the second one fixes got created by someone else.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]