Hi Torbjörn, sorry for the version confusion. I meant 6.2.0 and 6.2.1.
I am compiling using GitHub Actions which are running on Azure ( https://docs.microsoft.com/de-de/azure/virtual-machines/dv2-dsv2-series#dsv2-series) which is using Broadwell. Therefore the configure output is correct to assume Broadwell. As far as I have properly understood, the --enable-fat option should allow GMP to also work flawlessly on the Celeron i mentioned by selecting the appropriate optimization during runtime. But it does not, it quits with a SIGILL. Thread 11 "foo" received signal SIGILL, Illegal instruction. [Switching to Thread 0x7fffe37fe700 (LWP 9609)] 0x00005555571661db in __gmpn_set_str () (gdb) Here is a more complete stacktrace: #0 0x00005555571661db in __gmpn_set_str () #1 0x000055555715d90f in __gmpz_set_str () #2 0x0000555556e24c6c in convert_to_gmp (gmpnumber=0x7fffe2060c08, val=<optimized out>, base=<optimized out>) at /home/php-7.3.0/ext/gmp/gmp.c:748 #3 0x0000555556e26ff6 in zif_gmp_init (execute_data=<optimized out>, return_value=0x7fffe201c800) at /home/php-7.3.0/ext/gmp/gmp.c:1056 #4 0x000055555712b3c7 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at /home/php-7.3.0/Zend/zend_vm_execute.h:690 #5 execute_ex (ex=0x7fffcc25cd50) at /home/php-7.3.0/Zend/zend_vm_execute.h:55418 #6 0x0000555557130a30 in zend_execute (op_array=op_array@entry=0x7fffe2070000, return_value=0x0, return_value@entry=0x7fffecd616a0) at /home/php-7.3.0/Zend/zend_vm_execute.h:60834 #7 0x000055555709e364 in zend_execute_scripts (type=type@entry=8, retval=0x7fffecd616a0, retval@entry=0x0, file_count=-503200000, file_count@entry=3) at /home/php-7.3.0/Zend/zend.c:1568 #8 0x000055555703266e in php_execute_script (primary_file=0x7fffe3ffd490) at /home/php-7.3.0/main/main.c:2630 Does that help? The code works flawlessly on the Boardwell architecture (and a lot more!). The issue arises only on the mentioned Celeron. Michael Am Di., 27. Apr. 2021 um 10:19 Uhr schrieb Torbjörn Granlund <t...@gmplib.org >: > Michael Maroszek <par...@gmail.com> writes: > > i am using an unpatched gmplib version and the problem was introduced > with > version 6.20 (still exists in 6.21). Reverting to 6.1.2 solves the > problem. > > There are no GMP versions 6.20 or 6.21. Are these PHP releases, perhaps? > > The problem does not happen on all systems. Only a few users are > affected, > which use a specific NAS (and therefore CPU). Our app is running inside a > docker container and there seems to be at least one related bug report on > GitHub: https://github.com/home-assistant/core/issues/44538 > > The affected CPU is: Intel Celeron J3455 > > A CPU model GMP knows of. GMP matches it as goldmont. > > Unfortunately i don't have a full example app yet. It happens when using > the GMP functions in PHP. If definitely required I would do the work and > create a plain c app, but as far as i have seen the crash directly > happens > when using the gmp functions. (The crash always happens - it seems like > the > "fat" code doesn't detect the target system properly and uses an invalid > optimization) > > These are guesses. I strongly suggest that you debug it. > > Also, "crash" is is unnecessarily vague. > > #0 Object "/usr/bin/foo", at 0x55e4ff7368d9, in __gmpz_set_str > > 2021-04-01T12:29:38.2070642Z checking build system type... > broadwell-pc-linux-gnu > > If it is matched as broadwell-pc-linux-gnu, somebody is lying. That's > hardly what the cpuid instruction on a J3455 returns. > > -- > Torbjörn > Please encrypt, key id 0xC8601622 > _______________________________________________ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs