Hi Uros,

> On Fri, Nov 27, 2020 at 11:08 AM Rainer Orth
> <r...@cebitec.uni-bielefeld.de> wrote:
>>
>> When using the Solaris/x86 assembler with gcc, a couple of testcases
>> currently FAIL.  Those failures follow two patterns:
>>
>> FAIL: gcc.target/i386/avx512bw-vpmovb2m-2.c (test for excess errors)
>> Excess errors:
>> Assembler: avx512bw-vpmovb2m-2.c
>>         "/var/tmp//ccPh3IRc.s", line 58 : Invalid instruction argument
>>         Near line: "    vpmovb2m        %zmm0, %k0"
>>
>> and
>>
>> FAIL: gcc.target/i386/avx512dq-vreducesd-2.c (test for excess errors)
>> Excess errors:
>> Assembler: avx512dq-vreducesd-2.c
>>         "/var/tmp//ccVyU7Bc.s", line 54 : Invalid instruction argument
>>         Near line: "    vreducesd       $35, {sae}, %xmm0, %xmm0, %xmm7"
>>
>> The first only started with
>>
>> x86: relax mask register constraints
>>
>> 2019-01-04  Jan Beulich  <jbeul...@suse.com>
>>
>>         * config/i386/sse.md
>>         (<avx512>_cmp<mode>3<mask_scalar_merge_name><round_saeonly_name>,
>> [...]
>>
>> and is strange since even the current Intel 64 and IA-32 Architectures
>> Software Developer's Manual only lists %k1 for vpmovb2m and related
>> insns, and indeed the line assembles with %k0 changed to %k1.
>
> This is a bug in the assembler. SDE just indexes registers in this
> way, and %k0 can be assembled without problems:
>
>   0:   62 f2 7e 48 29 c0       vpmovb2m %zmm0,%k0

the SDM is confusingly expressed in this point.  Oh well...

>> The second is due to the use of {sae}: either this is a Solaris as bug
>> (the do claim AVX512DQ support) or they use a different syntax here:
>> omitting {sae} lets the line assemble as well.
>>
>> To avoid those failures, I've extended the avx512bw and avx512dq
>> effective-target checks to include code snippets that trigger the
>> generation of those insns.
>>
>> Tested no i386-pc-solaris2.11 with as (the failures are gone, as
>> expected) and gas (test results unchanged).
>>
>> Ok for master?
>
> I think we should not change the tests. These are clear bugs in the
> assembler, so they should be fixed in the assembler, not papered over
> in the testsuite.

Even if this happens, it will take some time until it reaches the field.
Besides, isn't it better to avoid lots of noise from failing tests with
a testsuite-only change that does no harm to working assemblers?

        Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Reply via email to