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