This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH 1/4] x86: correctly encode FSUBP
On Wed, Mar 7, 2018 at 4:54 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 07.03.18 at 13:39, <hjl.tools@gmail.com> wrote:
>> On Wed, Mar 7, 2018 at 4:36 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 07.03.18 at 13:30, <hjl.tools@gmail.com> wrote:
>>>> On Wed, Mar 7, 2018 at 1:47 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> While the combination of Intel syntax and AT&T mnemonics is bogus
>>>>> anyway, we nevertheless shouldn't mis-encode such insns.
>>>>>
>>>>> gas/
>>>>> 2018-03-07 Jan Beulich <jbeulich@suse.com>
>>>>>
>>>>> * testsuite/gas/i386/fsubp.l, testsuite/gas/i386/fsubp.s: New.
>>>>> * testsuite/gas/i386/i386.exp: Run new test.
>>>>>
>>>>> opcodes/
>>>>> 2018-03-07 Jan Beulich <jbeulich@suse.com>
>>>>>
>>>>> * i386-opc.tbl (fsubp): Correct encoding.
>>>>> * i386-tlb.h: Re-generate.
>>>>>
>>>>
>>>> I assume that no one uses it. Can't we simply drop it?
>>>
>>> I don't know, and would dare to chance it. But perhaps you know
>>> better than me. Of course, if we drop this one, there are others to
>>> be dropped at the same time.
>>
>> We are changing their encodings. If we can't drop them, it means
>> that someone is depending on their old encodings.
>
> Well, no, not exactly: If we do as you suggest, we should remove
> more than just this broken encoding. People may use some of the
> others, or may have happened to use the one here only with odd
> numbered registers. But again - I'm not entirely opposed to dropping
> the whole OldGcc logic, it's just that (at least at this point in time) it's
> not going to be me to do it. Hence rather than leaving things broken,
> I'd prefer to fix them. (As a side note, patch 3 and maybe also patch
> 4 of this series would probably need changing, just like a number of
> existing test cases.)
>
We should drop the broken encoding. If people do use them, they
will get an assembler error. Otherwise, they will get a run-time
error which is much harder to track down.
--
H.J.