From johanneskauffmann at hotmail.com Mon Sep 5 02:12:30 2022 From: johanneskauffmann at hotmail.com (Johannes Kauffmann) Date: Mon, 5 Sep 2022 02:12:30 +0200 Subject: Using WSL2 to cross-compile from Linux to Windows In-Reply-To: References: Message-ID: On 26/07/2022 21:56, Niels M?ller wrote: > Still makes sense to me. Could perhaps keep $CC at the *end* of the list? Maybe, maybe not. To me, the original patch seems better. When keeping $CC at the end of the list, you'll get a cryptic error message. With this patch, the message is clear. > I'm a bit annoyed by the related problem, that it is not enough to pass > --host to get cross_compilation set properly. For some backwards > compatiblity reasons one has to explicitly pass --build as well, even > when config.guess figures out the build system type perfectly right. > Documented in some detail at > https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#Hosts-and-Cross_002dCompilation Well, in this case, setting both --host and --build doesn't work. So I'd be glad if the patch in question could be integrated. The reason I'm asking is because there are a number of open-source projects affected by this bug, and would be benefited if this bug got resolved. Kinds regards, Johannes Kauffmann From bodrato at mail.dm.unipi.it Mon Sep 5 19:04:23 2022 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Mon, 05 Sep 2022 17:04:23 -0000 Subject: mini-gmp mpz_powm incorrect result In-Reply-To: <20220830082532.GW61030@zira.vinc17.org> References: <20220830082532.GW61030@zira.vinc17.org> Message-ID: <097d00bc93acf6ddf1fed0b87bdb3e6e@student.dm.unipi.it> Ciao, Il 2022-08-30 10:25 Vincent Lefevre ha scritto: >> or even (mn == 0 check just above this code rules out |m| < 1) >> >> mpz_set_ui (r, mpz_cmpabs_ui (m, 1)); I agree with this solution. Will you commit it? > Concerning this second solution, the GMP manual says: > > -- Function: int mpz_cmpabs_ui (const mpz_t OP1, unsigned long int > OP2) > Compare the absolute values of OP1 and OP2. Return a positive > value if abs(OP1) > abs(OP2), zero if abs(OP1) = abs(OP2), or a > negative value if abs(OP1) < abs(OP2). > > So if the mpz_cmpabs_ui implementation is changed so that it can > return a value larger than 1, you need to make sure to remember to > update the code. I propose to also add a couple of tests to mini-gmp/tests/t-powm.c , to keep track of this. ----8<------ diff -r b0d6b9f5807e mini-gmp/tests/t-powm.c --- a/mini-gmp/tests/t-powm.c Sat Aug 20 18:44:17 2022 +0200 +++ b/mini-gmp/tests/t-powm.c Mon Sep 05 19:02:23 2022 +0200 @@ -53,6 +53,31 @@ abort (); } } + + if (mpz_cmp_ui (res, 1) <= 0) + mpz_add_ui (res, res, 9); + + mpz_set_ui (e, 0); + /* Test the case m^0 (mod m), expect 1 (m is greater than 1). */ + mpz_powm (res, res, e, res); + if (mpz_cmp_ui (res, 1) != 0) + { + fprintf (stderr, "mpz_powm failed: b=m, e=0; 1 expected,\n"); + dump ("m", res); + dump ("r", res); + abort (); + } + + /* Now res is 1. */ + /* Test the case 1^0 (mod 1), expect 0. */ + mpz_powm (res, res, e, res); + if (mpz_size (res)) + { + fprintf (stderr, "mpz_powm failed: b=1, e=0, m=1; 0 expected,\n"); + dump ("r", res); + abort (); + } + mpz_clear (b); mpz_clear (e); mpz_clear (m); ----8<------ ?is, m From bodrato at mail.dm.unipi.it Mon Sep 5 19:17:11 2022 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Mon, 05 Sep 2022 17:17:11 -0000 Subject: mini-gmp mpz_powm incorrect result In-Reply-To: <097d00bc93acf6ddf1fed0b87bdb3e6e@student.dm.unipi.it> References: <20220830082532.GW61030@zira.vinc17.org> <097d00bc93acf6ddf1fed0b87bdb3e6e@student.dm.unipi.it> Message-ID: <7db345c2ce0f8c207228181875fe2649@student.dm.unipi.it> Il 2022-09-05 19:04 Marco Bodrato ha scritto: > Il 2022-08-30 10:25 Vincent Lefevre ha scritto: >>> or even (mn == 0 check just above this code rules out |m| < 1) >>> >>> mpz_set_ui (r, mpz_cmpabs_ui (m, 1)); > > I agree with this solution. Will you commit it? I incorrectly removed the "Niels M?ller wrote:" line. The question is for Niels, of course. > I propose to also add a couple of tests to mini-gmp/tests/t-powm.c , > to keep track of this. I'll push the tests just after the correction... ?is, m PS: thanks for the report From nisse at lysator.liu.se Mon Sep 5 21:23:07 2022 From: nisse at lysator.liu.se (Niels =?utf-8?Q?M=C3=B6ller?=) Date: Mon, 05 Sep 2022 19:23:07 -0000 Subject: mini-gmp mpz_powm incorrect result In-Reply-To: <097d00bc93acf6ddf1fed0b87bdb3e6e@student.dm.unipi.it> (Marco Bodrato's message of "Mon, 05 Sep 2022 19:04:20 +0200") References: <20220830082532.GW61030@zira.vinc17.org> <097d00bc93acf6ddf1fed0b87bdb3e6e@student.dm.unipi.it> Message-ID: Marco Bodrato writes: >>> or even (mn == 0 check just above this code rules out |m| < 1) >>> >>> mpz_set_ui (r, mpz_cmpabs_ui (m, 1)); > > I agree with this solution. Will you commit it? Committed, and I've verified that it fixes Guido's test case. > I propose to also add a couple of tests to mini-gmp/tests/t-powm.c , > to keep track of this. Definitely needed, thanks for looking into that. > ----8<------ > diff -r b0d6b9f5807e mini-gmp/tests/t-powm.c > --- a/mini-gmp/tests/t-powm.c Sat Aug 20 18:44:17 2022 +0200 > +++ b/mini-gmp/tests/t-powm.c Mon Sep 05 19:02:23 2022 +0200 > @@ -53,6 +53,31 @@ > abort (); > } > } > + > + if (mpz_cmp_ui (res, 1) <= 0) > + mpz_add_ui (res, res, 9); Adding 9 looks very arbitrary? > + mpz_set_ui (e, 0); > + /* Test the case m^0 (mod m), expect 1 (m is greater than 1). */ > + mpz_powm (res, res, e, res); Can we test mpz_powm (res, b, e, m), with e set to 0, and first |m| > 1, then m = ?1? To get coverage for various signs and values for b and m. BTW, it seems docs for mpz_powm doesn't say explicitly what 0^0 (mod m) should give? But docs for mpz_*_pow_ui does say that 0^0 yields 1, so for consitency, powm should give 1 mod m, which I think is what the code (with fix) does. Regards, /Niels -- Niels M?ller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677. Internet email is subject to wholesale government surveillance. From bodrato at mail.dm.unipi.it Thu Sep 8 22:42:34 2022 From: bodrato at mail.dm.unipi.it (Marco Bodrato) Date: Thu, 08 Sep 2022 20:42:34 -0000 Subject: mini-gmp mpz_powm incorrect result In-Reply-To: References: <20220830082532.GW61030@zira.vinc17.org> <097d00bc93acf6ddf1fed0b87bdb3e6e@student.dm.unipi.it> Message-ID: Ciao, Il 2022-09-05 21:23 nisse at lysator.liu.se ha scritto: > Marco Bodrato writes: >> I propose to also add a couple of tests to mini-gmp/tests/t-powm.c , >> to keep track of this. > > Definitely needed, thanks for looking into that. >> + if (mpz_cmp_ui (res, 1) <= 0) >> + mpz_add_ui (res, res, 9); > > Adding 9 looks very arbitrary? It is arbitrary. It is large enough to not be completely trivial and small enough to be short to write. I added a comment, saying that it is arbitrary :-) > Can we test mpz_powm (res, b, e, m), with e set to 0, and first |m| > > 1, > then m = ?1? To get coverage for various signs and values for b and m. The code handling e=0 is not so complex to deserve a sophisticated test. Anyway, of course the test can be improved. > BTW, it seems docs for mpz_powm doesn't say explicitly what 0^0 (mod m) > should give? But docs for mpz_*_pow_ui does say that 0^0 yields 1, so > for consitency, powm should give 1 mod m, which I think is what the > code > (with fix) does. Especially for _powm it is a good idea to return [1] for any x^0, regardless of x (i.e. also when x is 0). Otherwise, we should check whether x is 0 or not mod m. We just added the exception that the class [1] is represented by 0 when the modulus m=0. But that's not an exception wrt the above idea. ?is, m From ercli at ucdavis.edu Fri Sep 16 22:34:58 2022 From: ercli at ucdavis.edu (Eric Li) Date: Fri, 16 Sep 2022 16:34:58 -0400 Subject: GMP does not detect float exponent overflow while reading floating point numbers Message-ID: While using GMP to read floating point numbers, I noticed that when the exponent is too large, the exponent overflows without warning or error. GMP version: gmp-6.2.1-2.fc36.x86_64, installed using dnf on Fedora 36. Test program: a.c and b.cpp, see attachment. To run a.c, use "gcc a.c -o a -lgmp && ./a". The output on my machine is "0.1e-3215911262793760767". To run b.cpp, use "g++ b.cpp -o b -lgmp -lgmpxx && ./b". The output on my machine is "1e+-1294967296". The results are wrong because I entered a very large number, but got a number between 0 and 1. I am expecting GMP to return an error in mpf_init_set_str() indicating that the exponent is too large. Thanks to?https://stackoverflow.com/a/73740744, looks like the cause of the bug it that GMP triggered a signed overflow in the following code (from?https://gmplib.org/repo/gmp/file/feb796a7f683/mpf/set_str.c#l315) : while (dig < exp_base) { exp_in_base = exp_in_base * exp_base; exp_in_base += dig; c = (unsigned char) *expptr++; dig = digit_value[c]; } My gcc version information: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/12/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable- languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr -- mandir=/usr/share/man --infodir=/usr/share/info --with- bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable- threads=posix --enable-checking=release --enable-multilib --with- system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions -- enable-gnu-unique-object --enable-linker-build-id --with-gcc-major- version-only --enable-libstdcxx-backtrace --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with- isl=/builddir/build/BUILD/gcc-12.2.1-20220819/obj-x86_64-redhat- linux/isl-install --enable-offload-targets=nvptx-none --without-cuda- driver --enable-offload-defaulted --enable-gnu-indirect-function -- enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64- redhat-linux --with-build-config=bootstrap-lto --enable-link- serialization=1 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.1 20220819 (Red Hat 12.2.1-1) (GCC) My uname -a: Linux HOSTNAME 5.19.8-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Sep 8 19:02:21 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux -------------- next part -------------- A non-text attachment was scrubbed... Name: a.c Type: text/x-csrc Size: 285 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: b.cpp Type: text/x-c++src Size: 165 bytes Desc: not available URL: From brookner.a at gmail.com Fri Sep 16 07:57:34 2022 From: brookner.a at gmail.com (Aaron) Date: Thu, 15 Sep 2022 22:57:34 -0700 Subject: Using make tune, speed_measure error Message-ID: Hi y'all, I'm doing a clean build of GMP 6.2.1, trying to follow all of the steps finally. My "./configfsf.guess" output is "x86_64-pc-linux-gnu", and this is basically the same infothat "./config.guess" and "uname -a" produces. I built using "./configure" and make, this went fine I think. Then I cd'ed into /tune and ran "make tune". I think it runs through most of this makefile fine. In particular, after running "make tune" a 2nd time, it says "'tuneup' is up to date" and leaves tune/ directory. It outputs the parameters for "gmp-mparam.h", and then #define's a bunch of constants. The last constants it defines before the error are #define MUL_TOOM6H_THRESHOLD 298 #define MUL_TOOM8H_THRESHOLD 406 Reading the gmp-mparam.h file, I guess it's failing the next test, for optimizing MUL_TOOM32_TO_TOOM43_THRESHOLD? The error then goes " speed_measure() could not get 4 results within 1.0% ... (2 column table. The first row says "is about 1.0%" in a 3rd column, but blank for the other rows) ... ", and the next line reads "Aborted (core dumped)". if that's informative. I can include the table data or whatever else might be helpful. Thank y'all for GMP, it's amazing! Best, Aaron From Paul.Zimmermann at inria.fr Fri Sep 30 08:48:20 2022 From: Paul.Zimmermann at inria.fr (Paul Zimmermann) Date: Fri, 30 Sep 2022 08:48:20 +0200 Subject: GMP does not detect float exponent overflow while reading floating point numbers In-Reply-To: (message from Eric Li on Fri, 16 Sep 2022 16:34:58 -0400) References: Message-ID: Hi Eric, > GMP version: gmp-6.2.1-2.fc36.x86_64, installed using dnf on Fedora 36. > Test program: a.c and b.cpp, see attachment. > To run a.c, use "gcc a.c -o a -lgmp && ./a". The output on my machine > is "0.1e-3215911262793760767". > To run b.cpp, use "g++ b.cpp -o b -lgmp -lgmpxx && ./b". The output on > my machine is "1e+-1294967296". > The results are wrong because I entered a very large number, but got a > number between 0 and 1. I am expecting GMP to return an error in > mpf_init_set_str() indicating that the exponent is too large. on gmplib.org you can read: High-level floating-point arithmetic functions (mpf). This is the GMP function category to use if the C type `double' doesn't give enough precision for an application. There are about 70 functions in this category. New projects should strongly consider using the much more complete GMP extension library mpfr instead of mpf. Indeed with the following MPFR program you will get: $ gcc -g /tmp/b.c -lmpfr $ ./a.out @Inf@ $ cat /tmp/b.c #include #include #include int main(void) { mpfr_t f; const char *s = "1e3000000000000000000000000000000"; mpfr_init_set_str(f, s, 10, MPFR_RNDN); mpfr_out_str (stdout, 10, 100, f, MPFR_RNDN); printf("\n"); } Hope this helps, Paul From vincent at vinc17.net Fri Sep 30 12:20:20 2022 From: vincent at vinc17.net (Vincent Lefevre) Date: Fri, 30 Sep 2022 12:20:20 +0200 Subject: Please change http://mpfr.org to https://www.mpfr.org/ Message-ID: <20220930102020.GD12856@zira.vinc17.org> Hi, The GMP manual doc/gmp.texi currently has @url{http://mpfr.org}. But mpfr.org is poorly handled by Inria (no certificate and the redirection to https://www.mpfr.org/ does not always work, possibly to a temporary URL like currently, as one obtains mpfr.loria.fr). This URL should be changed to https://www.mpfr.org/ The http://mpfr.org URL in doc/projects.html should be updated too. Thanks, -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) From vincent at vinc17.net Fri Sep 30 14:29:01 2022 From: vincent at vinc17.net (Vincent Lefevre) Date: Fri, 30 Sep 2022 14:29:01 +0200 Subject: GMP does not detect float exponent overflow while reading floating point numbers In-Reply-To: References: Message-ID: <20220930122901.GF2025@cventin.lip.ens-lyon.fr> On 2022-09-16 16:34:58 -0400, Eric Li wrote: > Thanks to?https://stackoverflow.com/a/73740744, looks like the cause of > the bug it that GMP triggered a signed overflow in the following code > (from?https://gmplib.org/repo/gmp/file/feb796a7f683/mpf/set_str.c#l315) [...] I've given an answer: https://stackoverflow.com/a/73906883/3782797 This is not a bug. This is documented in the GMP manual: The 'mpf' functions and variables have no special notion of infinity or not-a-number, and applications must take care not to overflow the exponent or results will be unpredictable. As Paul said, you should use GNU MPFR if you want well-defined behavior. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)