From eggert at cs.ucla.edu Fri Jun 13 23:36:35 2025 From: eggert at cs.ucla.edu (Paul Eggert) Date: Fri, 13 Jun 2025 14:36:35 -0700 Subject: Should GMP_BPSW_NOFALSEPOSITIVES_UPTO_64BITS default to 1? Message-ID: <23e22495-51ef-4db8-9b85-43b16e327398@cs.ucla.edu> Currently mpz/millerrabin.c contains this: #ifndef GMP_BPSW_NOFALSEPOSITIVES_UPTO_64BITS #define GMP_BPSW_NOFALSEPOSITIVES_UPTO_64BITS 0 #endif It would be helpful to have a comment as to why the default is 0, as I see indications in the published literature that defaulting to 1 should be safe for Baillie PSW. Alternatively, we could change the default to 1. Something like the following, perhaps: /* By default assume no BPSW false positives < 2^64, as per: Gilchrist J. Pseudoprime Enumeration with Probabilistic Primality Tests. 2013-07-01. https://gilchrist.great-site.net/jeff/factoring/pseudoprimes.html Also see: Ishmukhametov ST, Mubarakov BG, Rubtsova RG, Oleinikova EV. On the Baillie PSW Conjecture. Russ Math. 2024-08-06;68(4):72-78. https://doi.org/10.3103/S1066369X24700294 */ #ifndef GMP_BPSW_NOFALSEPOSITIVES_UPTO_64BITS #define GMP_BPSW_NOFALSEPOSITIVES_UPTO_64BITS 1 #endif From stli at linux.ibm.com Tue Jun 24 10:04:28 2025 From: stli at linux.ibm.com (Stefan Liebler) Date: Tue, 24 Jun 2025 10:04:28 +0200 Subject: Fix gexpr.c due to gcc 15 incompatible pointer type warnings Message-ID: <10d666dc-e355-4767-a6f6-d2f68d8e1e1e@linux.ibm.com> Hi, According to https://my.eng.utah.edu/~pajensen/ACM/Documentation/gmplib.org/gmpbench.html To run the benchmarks, you also need to compile gexpr.c and put it somewhere in your path. I've downloaded https://gmplib.org/gexpr.c and got those warnings with gcc 15: gexpr.c:130:12: error: initialization of ?double (*)(void)? from incompatible pointer type ?double (*)(double)? [-Wincompatible-pointer-types] 130 | {"log2", my_log2}, | ^~~~~~~ gexpr.c:130:12: note: (near initialization for ?fns[0].evalfn?) gexpr.c:123:1: note: ?my_log2? declared here 123 | my_log2 (double x) | ^~~~~~~ gexpr.c:131:13: error: initialization of ?double (*)(void)? from incompatible pointer type ?double (*)(double)? [-Wincompatible-pointer-types] 131 | {"log10", log10}, | ^~~~~ ... SNIP: multiple more for all functions in fns-array. Simply adjusting the function prototype silences those warnings: --- gexpr_orig.c 2025-06-24 09:40:21.747880242 +0200 +++ gexpr.c 2025-06-24 09:31:13.507903946 +0200 @@ -116,7 +116,7 @@ struct functions { char *spelling; - double (* evalfn) (); + double (* evalfn) (double); }; double Can you please adjust https://gmplib.org/gexpr.c? Bye, Stefan Liebler From mikpelinux at gmail.com Sat Jun 28 22:07:23 2025 From: mikpelinux at gmail.com (Mikael Pettersson) Date: Sat, 28 Jun 2025 22:07:23 +0200 Subject: [PATCH] fix excess precision issue in tests/mpf/t-get_d.c Message-ID: <20250628200722.825913-2-mikpelinux@gmail.com> Building gmp-6.2.1, 6.3.0, or current tip, for m68020-linux results in a failure in the test suite: make[5]: Entering directory '../tests/mpf' ... ../test-driver: line 112: 18165 Aborted "$@" >> "$log_file" 2>&1 FAIL: t-get_d This is a regression from gmp-6.1.2 and earlier. The cause is that a change between 6.1 and 6.2 enabled the code in test_denorms, and that code is sensitive to excess precision. GMP has a FORCE_DOUBLE macro to work around such issues, but it's not used here. Using it in a similar way as in tests/mpn/t-get_d.c fixes the test case. Tested on m68k-linux-gnu (68040). Signed-off-by: Mikael Pettersson --- tests/mpf/t-get_d.c | 1 + 1 file changed, 1 insertion(+) Note: please use my @acm.org address in any replies. diff --git a/tests/mpf/t-get_d.c b/tests/mpf/t-get_d.c index 4e4c741f1..9687cd94e 100644 --- a/tests/mpf/t-get_d.c +++ b/tests/mpf/t-get_d.c @@ -60,6 +60,7 @@ test_denorms (int prc) if (d1 != d2) abort (); d1 *= 0.4; + FORCE_DOUBLE (d1); } mpf_clear (f); -- 2.49.0