Potential issue with --enable-fat

Marc Glisse marc.glisse at inria.fr
Sat Feb 8 13:58:30 CET 2025


On Fri, 7 Feb 2025, Emmanuel Lonca wrote:

> I recently got an issue (crashes due to SIGILL) while using GMP through Rug.
> After some investigation, I found out that the MULX instruction (from 
> the BMI2 instruction set) was called by __gmpz_sizeinbase on a system 
> which CPU does not support it.
> I first opened a ticket on the Rug repository (here: 
> https://gitlab.com/tspiteri/rug/-/issues/79).
>
> Long story short (more details in the ticket above), GMP was compiled 
> with the --enable-fat flag on a machine equipped with a CPU that has the 
> BMI2 instruction set (Intel(R) Xeon(R) CPU E5-2637 v4) and used on a 
> machine which has not access to these instructions (Intel(R) Xeon(R) CPU 
> E5-2643).
> To what I understand from the GMP documentation, compiling with the 
> --enable-fat flag should produce a library that can be used on any x86 
> architecture.

Let's see. If I configure GMP with just --enable-fat, I still see in 
config.h

#define HAVE_HOST_CPU_nehalem 1

and longlong.h enables mulx based on

#if X86_ASM_MULX \
    && (HAVE_HOST_CPU_haswell || HAVE_HOST_CPU_broadwell \
        || HAVE_HOST_CPU_skylake || HAVE_HOST_CPU_bd4 || HAVE_HOST_CPU_zen)

You can avoid this problem by explicitly telling configure what base 
system you are targeting (with --host, or even --build).

I am not sure what exactly is meant to happen, if --enable-fat should 
always come with an explicit host specification, or if we should 
automatically downgrade the guessed host type when we see --enable-fat.

-- 
Marc Glisse


More information about the gmp-bugs mailing list