Re: [PATCH] x86: Replace evex-no-scale.s with evex-no-scale-[32|64].s

["Jan Beulich" <JBeulich at suse dot com>]

>>> On 13.08.18 at 14:37, <hjl.tools@gmail.com> wrote:
> On Mon, Aug 13, 2018 at 5:01 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 13.08.18 at 13:29, <hjl.tools@gmail.com> wrote:
>>> On Sun, Aug 12, 2018 at 11:20 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 10.08.18 at 19:28, <hjl.tools@gmail.com> wrote:
>>>>> .if is_64bit
>>>>>       vmovaps -1024(%rip), %zmm0
>>>>>       vmovaps 64(,%rax), %zmm0
>>>>>       vmovaps 64(,%riz), %zmm0
>>>>> .endif
>>>>>
>>>>> doesn't with i686-elf cross binutils on 64-bit hosts:
>>>>>
>>>>> evex-no-scale.s: Assembler messages:
>>>>> evex-no-scale.s:10: Error: bad register name `%rip)'
>>>>> evex-no-scale.s:11: Error: bad register name `%rax)'
>>>>> evex-no-scale.s:12: Error: bad register name `%riz)'
>>>>
>>>> Mind shedding some light on the _actual_ issue? The fact that
>>>> the 64-bit code won't assemble with a 32-bit assembler doesn't
>>>> come as a surprise. The question is why is_64bit is set in this
>>>> case. I was actually meaning to use this approach in further
>>>> tests, to reduce the split / redundancy between similar or even
>>>> close to identical 32- and 64-bit tests.
>>>
>>> I didn't investigate further.  You can try it yourself.
>>
>> Well, I'll try to remember to do so eventually, but I'm sorry - this is
>> not a reasonable way to fix a test suite issue in my opinion. You
>> should first understand what the issue is, and only on that basis
>> decide how to best address the issue. I'd really like to ask you to
>> revert your "fix" given this situation. This is even worse than
>> requiring test sources to all have bogus .align directives at their
>> ends.
> 
> "make check" result for "i686-elf" target was clean before that
> testcase was added.  This is a less intrusive way to fix it on master
> and backport it to 2.31 branch.

That's all fine, but if for a 32-bit target "inc %eax" does not produce
a 1-byte encoding, then there's quite likely something broken
elsewhere. Your change hides this brokenness rather than keeping it
exposed until it's fixed (or until it's understood that this is expected
and my assumptions are wrong upon which I've built the test case).

Jan