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