Mulx: Illegal Instruction

[Paul Peet]

Thanks for the response :).
So I should try to recompile gmp with -mno-bmi -mno-bmi2 ? If so I
hope gcc wont' crash then because it's actually using gmp somehow.

On Wed, Dec 2, 2015 at 5:57 PM, Leif Leonhardy <not.really at online.de> wrote:
> Torbjörn Granlund wrote:
>> Paul Peet <peetpaul69 at gmail.com> writes:
>>
>>   Distro: Arch Linux (x86_64)
>>   CPU: Intel Pentium G4400 (Skylake)
>>   Kernel: Linux Kernel 4.2.5-1-ARCH
>>   GMP-Version: 6.1.0
>>   GCC: 5.2.0
>>
>>   I discovered this bug while trying to compiling the linux kernel but
>>   it ultimately failed.
>>   The issue which occured was an SIGILL one. I traced down the issue
>>   back to the assembly code and the result was that
>>   it was executing a mulx instruction which apparently is invalid here
>>   on my cpu (Pentium G4400).
>>   A member suggested that it might be an issue with the detection logic in gmp.
>>
>>   For more detailed overview of the issue:
>>   https://bbs.archlinux.org/viewtopic.php?id=205703
>>
>>   Disassembly of the illegal instruction:
>>   Dump of assembler code for function __gmpn_sqr_basecase_coreibwl:
>>      0x00007ffff7708000 <+0>: cmp    $0x2,%rdx
>>      0x00007ffff7708004 <+4>: jae    0x7ffff7708016
>>   <__gmpn_sqr_basecase_coreibwl+22>
>>      0x00007ffff7708006 <+6>: mov    (%rsi),%rdx
>>   => 0x00007ffff7708009 <+9>: mulx   %rdx,%rax,%rdx
>>
>> I would expect skylake to come with MULX (which were introduced with
>> haswell) as well as ADX (which were introduced with broadwell)..
>>
>> Perhaps Intel fused them out in an attempt to make a low-end product
>> less attractive.  I'll ask.
>
> None of the Pentium G Skylakes have AVX (just SSE 4.1/4.2) [1], nor
> apparently BMI2.
>
> Quoting Intel [2]:
>
> "It is important to understand that a new instruction is supported on a
> particular processor only if the corresponding CPUID feature flag is
> set.  Applications must not assume support of any instruction set
> extension simply based on, for example, checking a CPU model or family
> and must instead always check for _all_ the feature CPUID bits of the
> instructions being used."
>
> InterestinglyTM, the Spec Update for the Skylake processors [3, PDF
> only] lists the following:
>
> ------------------------------------------------------------------------
> SKD052:  CPUID Incorrectly Reports Bit Manipulation Instructions Support
>
> Problem:  Executing CPUID with EAX = 7 and ECX = 0 may return EBX with
> bits [3] and [8] set, incorrectly indicating the presence of BMI1 and
> BMI2 instruction set extensions.
>
> Implication:  Attempting to use instructions from the BMI1 or BMI2
> instruction set extensions will result in a #UD exception.
>
> Workaround:  It is possible for the BIOS to contain a workaround for
> this erratum.
>
> Status:  No fix.  Affects 6th Generation Intel® Pentium® processor
> family and Intel® Celeron® processor family.
> ------------------------------------------------------------------------
>
>
> So at least for now, configuring with 'ivybridgenoavx' seems to be the
> right thing to do.  (Adding in addition '-mno-bmi -mno-bmi2' to CFLAGS
> isn't necessary in this case.)
>
>
> @Paul:  You probably have to recompile a couple of packages with
> modified CFLAGS / '-march=...' etc.
>
>
> -leif
>
> [1] http://ark.intel.com/products/88179
>
> [2]
> https://software.intel.com/en-us/articles/how-to-detect-new-instruction-support-in-the-4th-generation-intel-core-processor-family
>
> [3]
> http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf
> (page 30, 11)
>
>> We encountered a similar situation with AVX challenged haswells.
>> It will be too much work for us to support a matrix of
>> (microarchitectures x fused instructions).  We will handle this new
>> world by dropping back to an older microarchitecture where the fused
>> instruction exists.  E.g., a skylake without MULX will be treated as an
>> ivybridge.
>