[PATCH 1/4] x86: correctly encode FSUBP

[Jan Beulich]

>>> On 07.03.18 at 14:26, <hjl.tools@gmail.com> wrote:
> 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.

Well, again - we should drop all that OldGcc cruft, or keep it and fix
it. Leaving something broken around is simply bad, and leaving OldGcc
partially implemented isn't much better.

Jan