This is the mail archive of the binutils@sourceware.org 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: [PATCH] x86: allow suffix-less sign-extending movsb, movsw, and movsl


>>> On 01.07.16 at 18:20, <hjl.tools@gmail.com> wrote:
> On Fri, Jul 1, 2016 at 9:19 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 01.07.16 at 18:14, <hjl.tools@gmail.com> wrote:
>>> On Fri, Jul 1, 2016 at 9:12 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 01.07.16 at 18:07, <hjl.tools@gmail.com> wrote:
>>>>> On Fri, Jul 1, 2016 at 8:32 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>>> On 01.07.16 at 17:23, <hjl.tools@gmail.com> wrote:
>>>>>>> On Fri, Jul 1, 2016 at 8:19 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>>>>> On 01.07.16 at 17:12, <hjl.tools@gmail.com> wrote:
>>>>>>>>> On Fri, Jul 1, 2016 at 7:55 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>>>>>>>> On 01.07.16 at 16:24, <jonas-devlists@watlock.be> wrote:
>>>>>>>>>>> So in the end, I guess the movzb/movzw change is fine, but this one is
>>>>>>>>>>> not. It's in inherent inconsistency related to the ability of leaving
>>>>>>>>>>> away the size suffixes in combination with the chosen mnemonics, it
>>>>>>>>>>> seems.
>>>>>>>>>>
>>>>>>>>>> I do not understand what inconsistency you refer to here. The
>>>>>>>>>> only inconsistency I can see is that one can't omit the suffixes
>>>>>>>>>> from these three instructions, unlike any others with GPR
>>>>>>>>>> operands.
>>>>>>>>>
>>>>>>>>> This mnemonic inconsistency comes from ISA and AT&T syntax.
>>>>>>>>> But there are no issues now.
>>>>>>>>
>>>>>>>> There is - as said, I fell into the trap seeing "movzb" in source code
>>>>>>>> and assuming I then could also use "movzw" or "movsb" (etc). I
>>>>>>>> can certainly open a bug if that helps you re-consider.
>>>>>>>
>>>>>>> It is unfortunate.  But it won't lead to wrong instructions being used.
>>>>>>
>>>>>> So since I see that rational arguments won't lead anywhere here
>>>>>> - would you at least allow in the fix for the bug that this change
>>>>>> uncovered (the one hunk changing tc-i386.c), even if that also
>>>>>> doesn't seem to cause any issues right now?
>>>>>
>>>>> Please open a bug report with a testcase.
>>>>
>>>> You're kidding? As said, the issue got uncovered only with the
>>>> other adjustments here; I'm not aware of a case where this
>>>> would cause a problem without the other changes, and I'm not
>>>> going to spend a whole lot of time trying to figure a broken case.
>>>
>>> So there is no issue with the current code base?
>>
>> I'm not aware of one (other than the source looking wrong), but
>> I can't say there is none.
> 
> I'd like to leave it alone unless there is an issue with assembly input.

Well, as almost always with leaving in place visibly wrong code,
there is an issue with it, and I've just sent a patch with just that
fix and respective tests added. I have to admit that I really dislike
the attitude of waiting for issues to be run into when they can be
dealt with proactively.

Jan


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