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: reject further invalid AVX-512 masking constructs


>>> On 21.11.17 at 23:18, <hjl.tools@gmail.com> wrote:
> On Mon, Nov 20, 2017 at 6:24 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 20.11.17 at 15:10, <hjl.tools@gmail.com> wrote:
>>> On Mon, Nov 20, 2017 at 6:06 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> --- a/gas/testsuite/gas/i386/inval-avx512f.s
>>>> +++ b/gas/testsuite/gas/i386/inval-avx512f.s
>>>> @@ -48,3 +48,6 @@ _start:
>>>>         vaddps zmm2, zmm1, ZMMWORD PTR [eax]{1to16}
>>>>         vaddps zmm2, zmm1, DWORD PTR [eax]
>>>>         vaddpd zmm2, zmm1, QWORD PTR [eax]
>>>> +
>>>> +       vaddps zmm2{ecx}, zmm1, zmm0
>>>> +       vaddps zmm2{z}, zmm1, zmm0
>>>
>>> Do they fail only in Intel syntax?  Testcases in AT&T syntax iare
>>> required unless they are specific to Intel syntax.
>>
>> They fail in both modes. The way the test cases are written which
>> I'm modifying makes it rather ugly to insert AT&T tests. If you
>> want to really force me to do that juggling, may I please ask that
>> on _all_ future tests, line number and section offsets should either
>> be expressed by regex-es or, should their checking be a requirement
>> (like is the case here), Intel and AT&T syntax inputs go into different
>> files so one can easily add to the end of a file without having to flip
>> flop between syntaxes?
>>
>> Please clarify your expectations.
> 
> All error checkings should have a testcase in AT&T syntax, unless they
> are specific to Intel syntax.  You can create a new input file to avoid a
> large diff on output of existing test.

Creating a new input file is as bad as having to fiddle with badly
written ones: Similar type tests really belong together, and a
growing number of test cases has more impact on overall testsuite
execution time than adding a few lines to an existing input. I really
try apply proper reasoning when picking between adding to existing
tests vs introducing new ones. Hence while I'm intending to do what
you ask for here, I at the same time would have hoped for you to
agree to look a little more closely at new tests before allowing them
in, making sure they're written in an extensible way.

And btw, this logically extends to writing test output expectations
in a way to only check for what's really meaningful in a test - going
back to you disagreeing with many of my uses of ? in regex-es. If
you or anyone else cares for e.g. the optional ",1" in an AT&T
memory operand to be produced by the disassembler, this should
be done by a dedicated test. That way, once we can settle on the
disassembler to produce more readable output (just like by default
it omits suffixes, despite them being no more or less optional than
that scaling specifier), it would be exactly one place in the test
suite which needs modifying (be it by adding a command line option
or by adjusting expected output).

Jan


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