From skir at sagemath.org Wed Jul 9 11:12:50 2025 From: skir at sagemath.org (Sergey B Kirpichev) Date: Wed, 9 Jul 2025 11:12:50 +0200 Subject: status of --enable-nails Message-ID: Hello, recently I tried to compile gmp from the repo with this option, that ended with: $ ./configure -q --enable-nails checking ABI=64 using ABI="64" CC="gcc" CFLAGS="-O2 -pedantic -fomit-frame-pointer -m64 -mtune=slm -march=slm" CPPFLAGS="" MPN_PATH=" x86_64/silvermont/nails x86_64/silvermont x86_64/atom/nails x86_64/atom x86_64/nails x86_64 generic" configure: error: no version of invert_limb_table found in path: x86_64/silvermont/nails x86_64/silvermont x86_64/atom/nails x86_64/atom x86_64/nails x86_64 generic $ ls -d mpn/*/nails/ mpn/*/*/nails/ ls: cannot access 'mpn/*/nails/': No such file or directory mpn/alpha/ev6/nails/ Is that option supported for Intel processors? PS: $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm $ uname -a Linux note 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64 GNU/Linux From tg at gmplib.org Sun Jul 13 17:15:30 2025 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn_Granlund?=) Date: Sun, 13 Jul 2025 17:15:30 +0200 Subject: status of --enable-nails In-Reply-To: (Sergey B. Kirpichev's message of "Wed, 9 Jul 2025 11:12:50 +0200") References: Message-ID: <865xfwktpp.fsf@shell.gmplib.org> Unfortunately, the "nails" stuff is not maintained. It was always considered experimental, and was only useful for a few generations of CPUs quite some time ago (e.g., Alpha 21264). (Come to think about it, it might be usable for RISC 5 if there is any chip with high-performance mul/mulhu. I haven't followed RISC 5 as its ISA will never allow for competitive bignum performance.) -- Torbj?rn Please encrypt, key id 0xC8601622 From anton at a4.complang.tuwien.ac.at Mon Jul 14 19:03:05 2025 From: anton at a4.complang.tuwien.ac.at (Anton Ertl) Date: Mon, 14 Jul 2025 19:03:05 +0200 Subject: status of --enable-nails In-Reply-To: <865xfwktpp.fsf@shell.gmplib.org> References: <865xfwktpp.fsf@shell.gmplib.org> Message-ID: On Sun, Jul 13, 2025 at 05:15:30PM +0200, Torbj?rn Granlund wrote: > I haven't followed RISC 5 as its > ISA will never allow for competitive bignum performance.) This is a very citable statement:-) I have written a paper about extending GPRs with carry and overflow bits. This feature would be especially useful for an architecture that does not have carry and overflow bits, such as RISC-V, so I give a RISC-V extension with these features as example. I sent the paper to several conferences, and it was rejected. Some of the suggestions by the reviewers would require a lot of work (implement the extension in (simulated) hardware to show the hardware cost, make use of the extension in a compiler to show the compiler benefits). But I fear that even if I would satisfy these wishes, another objection would still prevail: How relevant is such an extension? What proportion of CPU time is spent in multi-precision arithmentics? If any of you has good numbers on that, the statement above might gain some more teeth. - anton From tg at gmplib.org Tue Jul 15 13:33:50 2025 From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn_Granlund?=) Date: Tue, 15 Jul 2025 13:33:50 +0200 Subject: status of --enable-nails In-Reply-To: (Anton Ertl's message of "Mon, 14 Jul 2025 19:03:05 +0200") References: <865xfwktpp.fsf@shell.gmplib.org> Message-ID: <86v7ntlmch.fsf@shell.gmplib.org> Anton Ertl writes: On Sun, Jul 13, 2025 at 05:15:30PM +0200, Torbj?rn Granlund wrote: > I haven't followed RISC 5 as its > ISA will never allow for competitive bignum performance.) This is a very citable statement:-) There was a discussion on RISC 5 back in 2021 on the gmp-devel list: https://gmplib.org/list-archives/gmp-devel/2021-September/006013.html -- Torbj?rn Please encrypt, key id 0xC8601622 From mac at mcrowe.com Mon Jul 21 18:04:01 2025 From: mac at mcrowe.com (Mike Crowe) Date: Mon, 21 Jul 2025 17:04:01 +0100 Subject: Uninitialised memory after mpn_sec_tabselect on i686 Message-ID: I'm having some trouble with Valgrind reporting use of uninitialised memory from code using gnutls on 32-bit x86 and I believe that I have narrowed the problem down to the x86 asm version of mpn_sec_tabselect. The problem goes away if I configure gmp with --disable-assembly. If I insert VALGRIND_CHECK_MEM_IS_DEFINED(rp, n) immediately after the call to mpn_sec_tabselect (rp, pp, n, 1 << windowsize, expbits) in mpn_sec_powm (sec_powm.c:353) then I get: ==2458744== Uninitialised byte(s) found during client check request ==2458744== at 0x56A86D7: __gmpn_sec_powm (sec_powm.c:353) ==2458744== by 0x7AFDD07: rsa_sec_blind (rsa-sign-tr.c:201) ==2458744== by 0x7AFDD07: _nettle_rsa_sec_compute_root_tr (rsa-sign-tr.c:336) ==2458744== by 0x7AFE0DA: nettle_rsa_compute_root_tr (rsa-sign-tr.c:377) ==2458744== by 0x7AFE70A: nettle_rsa_pkcs1_sign_tr (rsa-pkcs1-sign-tr.c:56) ==2458744== by 0x5A35160: _wrap_nettle_pk_sign (pk.c:1616) ==2458744== by 0x5998AB3: privkey_sign_and_hash_data (privkey.c:1344) ==2458744== by 0x5998D96: gnutls_privkey_sign_data2 (privkey.c:1235) ==2458744== by 0x59857DC: _gnutls_check_key_cert_match (cert-cred.c:1031) ==2458744== by 0x5992476: gnutls_certificate_set_x509_key_mem2 (cert-cred-x509.c:678) ... ==2458744== Address 0xa427374 is 4 bytes inside a block of size 512 alloc'd ==2458744== at 0x4E11616: malloc (vg_replace_malloc.c:446) ==2458744== by 0x56718EF: __gmp_default_allocate (memory.c:53) ==2458744== by 0x7B02CEE: _nettle_gmp_alloc (gmp-glue.c:310) ==2458744== by 0x7AFDB0A: _nettle_rsa_sec_compute_root_tr (rsa-sign-tr.c:332) ==2458744== by 0x7AFE0DA: nettle_rsa_compute_root_tr (rsa-sign-tr.c:377) ==2458744== by 0x7AFE70A: nettle_rsa_pkcs1_sign_tr (rsa-pkcs1-sign-tr.c:56) ==2458744== by 0x5A35160: _wrap_nettle_pk_sign (pk.c:1616) ==2458744== by 0x5998AB3: privkey_sign_and_hash_data (privkey.c:1344) ==2458744== by 0x5998D96: gnutls_privkey_sign_data2 (privkey.c:1235) ==2458744== by 0x59857DC: _gnutls_check_key_cert_match (cert-cred.c:1031) ==2458744== by 0x5992476: gnutls_certificate_set_x509_key_mem2 (cert-cred-x509.c:678) ... ==2458744== Uninitialised value was created by a heap allocation ==2458744== at 0x4E11616: malloc (vg_replace_malloc.c:446) ==2458744== by 0x56718EF: __gmp_default_allocate (memory.c:53) ==2458744== by 0x7B02CEE: _nettle_gmp_alloc (gmp-glue.c:310) ==2458744== by 0x7AFDB0A: _nettle_rsa_sec_compute_root_tr (rsa-sign-tr.c:332) ==2458744== by 0x7AFE0DA: nettle_rsa_compute_root_tr (rsa-sign-tr.c:377) ==2458744== by 0x7AFE70A: nettle_rsa_pkcs1_sign_tr (rsa-pkcs1-sign-tr.c:56) ==2458744== by 0x5A35160: _wrap_nettle_pk_sign (pk.c:1616) ==2458744== by 0x5998AB3: privkey_sign_and_hash_data (privkey.c:1344) ==2458744== by 0x5998D96: gnutls_privkey_sign_data2 (privkey.c:1235) ==2458744== by 0x59857DC: _gnutls_check_key_cert_match (cert-cred.c:1031) ==2458744== by 0x5992476: gnutls_certificate_set_x509_key_mem2 (cert-cred-x509.c:678) I believe that the following simple program, when built and run against gmp 6.3.0 or r18486:f1c983debf6c on Debian 12 configured with --host=i686-my-linux might show the same problem in a simpler way: --8<-- #include #include int main() { mpz_t rop, base, exp, mod; mpz_init(rop); mpz_init(base); mpz_init(exp); mpz_init(mod); mpz_set_si(base, 10); mpz_set_si(exp, 63); mpz_set_si(mod, 65537); mpz_powm_sec(rop, base, exp, mod); mpz_out_str(stdout, 10, rop); putchar('\n'); return 0; } -->8-- The valgrind 3.25.1 output from this program is: ==43680== Conditional jump or move depends on uninitialised value(s) ==43680== at 0x487707B: __gmpz_powm_sec (powm_sec.c:88) ==43680== by 0x4001124: main (reproduce.c:14) ==43680== ==43680== Conditional jump or move depends on uninitialised value(s) ==43680== at 0x4887B6F: mpn_bc_get_str (get_str.c:239) ==43680== by 0x4887F8B: __gmpn_get_str (get_str.c:430) ==43680== by 0x4876300: __gmpz_out_str (out_str.c:93) ==43680== by 0x4001137: main (reproduce.c:15) ==43680== ==43680== Conditional jump or move depends on uninitialised value(s) ==43680== at 0x4887B9C: mpn_bc_get_str (get_str.c:239) ==43680== by 0x4887F8B: __gmpn_get_str (get_str.c:430) ==43680== by 0x4876300: __gmpz_out_str (out_str.c:93) ==43680== by 0x4001137: main (reproduce.c:15) ==43680== ==43680== Use of uninitialised value of size 4 ==43680== at 0x487631E: __gmpz_out_str (out_str.c:97) ==43680== by 0x4001137: main (reproduce.c:15) ==43680== though Debian 12's valgrind 3.19 also reports the same. If, as before, I insert the same VALGRIND_CHECK_MEM_IS_DEFINED(rp, n) call immediately after the call to mpn_sec_tabselect (rp, pp, n, 1 << windowsize, expbits) in mpn_sec_powm (sec_powm.c:350) then it fires: ==50688== Uninitialised byte(s) found during client check request ==50688== at 0x48AB003: __gmpn_sec_powm (sec_powm.c:350) I do not see this problem when using Debian 12's gmp-6.2.1. Is this a real bug? Thanks. Mike.