From goxjanskloon at outlook.com Wed Jan 15 16:41:23 2025 From: goxjanskloon at outlook.com (_ goxjanskloon) Date: Wed, 15 Jan 2025 15:41:23 +0000 Subject: Failed to pass test "convert" on cross-compiled and shared libraries Message-ID: Basic information: * GMPGMP version: 6.3.0 * configure options: --build=x86_64-pc-linux-gnu --host=x86_64-w64-mingw32 --prefix=/home/gxj/bin --enable-shared --disable-static * configure output: See attachment configure.output * Compilers: See attachments *gcc.version * Output from uname -a: Linux DESKTOP-####### 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux * Output from config.guess: zen2-pc-linux-gnu * Output from configfsf.guess: x86_64-pc-linux-gnu * config.log: See attachment config.log Bug Detail: I cross-compiled GMP on Ubuntu WSL2 (from Windows 10), targeting Windows. I have package mingw-w64 installed from apt, to get a MinGW-w64 toolchain. I configured and built GMP successfully, without any errors but a warning during configuring: ??????configure: WARNING: cannot check for properly working vsnprintf when cross compiling, will assume it's ok. After looking up this warning, I thought it couldn't be an error, and ignored it, then ran make install. The output from installing reminded me to test, so I ran make check -j12(for output and log, see attachment tests-mpz-test-suite.log). I saw plenty warnings and errors from libtool (see attachment). I couldn't get anything helpful about it on the Internet. All tests passed, except convert. Sorry for my laziness, I couldn't understand the source code of this test. Only I know is that this test stopped exceptionally with exiting code 127. As far as I know, 127 means a command can't be found. But I couldn't see any system calls in convert.c. Recalling the warning I got during configuring, I guess it is related to function vsnprintf . (I saw a character serial in the source code, according to it and the name "convert", I guess it is about strings. But this is a multiprecision project! My idea may be foolish...) I tried to debug it. I cleaned my building directory and reconfigured by: ??????CFLAGS='-O0 -g -DDEBUG' CC_FOR_BUILD=gcc /path/to/configure --build=x86_64-pc-linux-gnu --host=x86_64-w64-mingw32 --prefix=/home/gxj/bin --enable-static --disable-shared --enable-alloca=debug --disable-assembly Everything went well, and every test passed (There was't any error or warning that is significant, so I don't attach the outputs and logs from it). The error I got previously didn't appear this time. I thought it might be related to the type of libraries. Because in the first build, I built shared libraries, and in the debugging build, I built static libraries, in order to get debugging symbols for GDB. I have experienced many problems about library types when I cross-compile from Linux to Windows. But this time I want to build an exactly as dynamic as possible toolchain, which includes GMP. So I need to know a workaround or a solution that isn't switching to static libraries. -------------- next part -------------- A non-text attachment was scrubbed... Name: attachments.7z Type: application/octet-stream Size: 6041 bytes Desc: attachments.7z URL: From albin.ahlback at gmail.com Fri Jan 17 16:42:43 2025 From: albin.ahlback at gmail.com (=?UTF-8?Q?Albin_Ahlb=C3=A4ck?=) Date: Fri, 17 Jan 2025 16:42:43 +0100 Subject: Apple M4 Pro is not recognized in config.guess Message-ID: <58d37d6b-49d4-4ec8-9868-e8d42edd03c7@gmail.com> Hi, I just tried to compile GMP on my Apple M4 Macbook Pro, and `config.guess' did not recognize my CPU as `applem4', but simply `aarch64'. I have the following: $ system_profiler SPHardwareDataType | grep Chip Chip: Apple M4 Pro Don't know if the pro models of previous generations are affected. I have patched this on my system, but it would be nice if it was patched on upstream as well. Best, Albin From Paul.Zimmermann at inria.fr Mon Jan 27 10:58:23 2025 From: Paul.Zimmermann at inria.fr (Paul Zimmermann) Date: Mon, 27 Jan 2025 10:58:23 +0100 Subject: [ping] bug in __gmp_replacement_vsnprintf Message-ID: Hi, this bug report from 3 years ago is still unanswered: https://gmplib.org/list-archives/gmp-bugs/2022-October/005200.html >From the last snapshot gmp-6.3.0-20241204172630, it seems %a/%A are still not handled. Please can you confirm this bug? Paul From marc.glisse at inria.fr Wed Jan 29 21:53:24 2025 From: marc.glisse at inria.fr (Marc Glisse) Date: Wed, 29 Jan 2025 21:53:24 +0100 (CET) Subject: bug in __gmp_replacement_vsnprintf In-Reply-To: References: Message-ID: <89c18068-b0f6-1328-09aa-4fe5059630a1@inria.fr> On Wed, 12 Oct 2022, Paul Zimmermann wrote: > The issue is because __gmp_replacement_vsnprintf does not deal with %a not %A. > Then when calling gmp_printf ("%a", -1.25) for example, we get total_width=3 > initially, we jump to the 'default' case, where the ASSERT(0) does nothing > in production code, and we go to next, where width=0 and prec=6, thus > total_width is increased to 9. But we also have len=9 because > buf='-0x1.4p+0'. Then the assertion ASSERT_ALWAYS (len < total_width) fails. Hi Paul, indeed, '%a' does not seem to be handled. Do you know what an appropriate upper bound on the size of the output would be? Trying to guess from the handling of 'f', 'g', etc: total_width += prec + 5 + floating_sizeof * 2; *2 because a byte (8 bits) only needs 2 hex (4 bits) +5 because 'g' as +3 and 'a' has the extra "0x" ? I would probably write +10 to have more margin, but I'd rather someone who understands these things give me the answer... Other than that, it feels wrong that this replacement function is still used on some windows configurations, visual studio has had vsnprintf for a long time now. There is also the possibility of using gnulib's version of vsnprintf if we don't want to maintain our own, but I think I'd rather make configure fail on missing vsnprintf to force users to configure their toolchain properly. -- Marc Glisse From vincent at vinc17.net Thu Jan 30 02:03:07 2025 From: vincent at vinc17.net (Vincent Lefevre) Date: Thu, 30 Jan 2025 02:03:07 +0100 Subject: bug in __gmp_replacement_vsnprintf In-Reply-To: <89c18068-b0f6-1328-09aa-4fe5059630a1@inria.fr> References: <89c18068-b0f6-1328-09aa-4fe5059630a1@inria.fr> Message-ID: <20250130010307.GD3207@qaa.vinc17.org> On 2025-01-29 21:53:24 +0100, Marc Glisse wrote: > On Wed, 12 Oct 2022, Paul Zimmermann wrote: > > > The issue is because __gmp_replacement_vsnprintf does not deal with %a not %A. > > Then when calling gmp_printf ("%a", -1.25) for example, we get total_width=3 > > initially, we jump to the 'default' case, where the ASSERT(0) does nothing > > in production code, and we go to next, where width=0 and prec=6, thus > > total_width is increased to 9. But we also have len=9 because > > buf='-0x1.4p+0'. Then the assertion ASSERT_ALWAYS (len < total_width) fails. > > Hi Paul, > > indeed, '%a' does not seem to be handled. Do you know what an appropriate > upper bound on the size of the output would be? > > Trying to guess from the handling of 'f', 'g', etc: > total_width += prec + 5 + floating_sizeof * 2; > > *2 because a byte (8 bits) only needs 2 hex (4 bits) You also need to take the exponent into account. If the exponent takes k bits, this would be of the order k * log(2)/log(10). So, if the exponent takes n bytes, this would be of the order 8n * log(2)/log(10) ? 2.4 n. So, instead of *2, you could choose *5/2 (2.5 being larger than 8 * log(2)/log(10)). > +5 because 'g' as +3 and 'a' has the extra "0x" The sign + "0x" + "p" + the sign of the exponent also give 5. But this assumes that you did not have width and precision fields. > Other than that, it feels wrong that this replacement function is still used > on some windows configurations, visual studio has had vsnprintf for a long > time now. There is also the possibility of using gnulib's version of > vsnprintf if we don't want to maintain our own, but I think I'd rather make > configure fail on missing vsnprintf to force users to configure their > toolchain properly. IIRC, the issue is that the version is MS Windows is buggy. This is no longer an issue in MinGW, where __USE_MINGW_ANSI_STDIO is now defined by default, if I understand correctly. GMP's vsnprintf is also used under OpenBSD 7+, which does not support %n. But I would say that it would be OK to consider that broken features in the system vsnprintf would also affect GMP, as long as they do not affect the specifiers with GMP types. -- Vincent Lef?vre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) From marc.glisse at inria.fr Fri Jan 31 21:57:33 2025 From: marc.glisse at inria.fr (Marc Glisse) Date: Fri, 31 Jan 2025 21:57:33 +0100 (CET) Subject: bug in __gmp_replacement_vsnprintf In-Reply-To: <20250130010307.GD3207@qaa.vinc17.org> References: <89c18068-b0f6-1328-09aa-4fe5059630a1@inria.fr> <20250130010307.GD3207@qaa.vinc17.org> Message-ID: Thank you for those precisions. I pushed something, not perfect but the MPFR testsuite seems ok with it. There are still a number of things not handled in this replacement function. If people want them fixed, please provide patches, I don't intend to waste more time on it. On Thu, 30 Jan 2025, Vincent Lefevre wrote: > On 2025-01-29 21:53:24 +0100, Marc Glisse wrote: >> On Wed, 12 Oct 2022, Paul Zimmermann wrote: >> >> > The issue is because __gmp_replacement_vsnprintf does not deal with %a not %A. >> > Then when calling gmp_printf ("%a", -1.25) for example, we get total_width=3 >> > initially, we jump to the 'default' case, where the ASSERT(0) does nothing >> > in production code, and we go to next, where width=0 and prec=6, thus >> > total_width is increased to 9. But we also have len=9 because >> > buf='-0x1.4p+0'. Then the assertion ASSERT_ALWAYS (len < total_width) fails. >> >> Hi Paul, >> >> indeed, '%a' does not seem to be handled. Do you know what an appropriate >> upper bound on the size of the output would be? >> >> Trying to guess from the handling of 'f', 'g', etc: >> total_width += prec + 5 + floating_sizeof * 2; >> >> *2 because a byte (8 bits) only needs 2 hex (4 bits) > > You also need to take the exponent into account. If the exponent > takes k bits, this would be of the order k * log(2)/log(10). So, > if the exponent takes n bytes, this would be of the order > 8n * log(2)/log(10) ? 2.4 n. > > So, instead of *2, you could choose *5/2 (2.5 being larger than > 8 * log(2)/log(10)). > >> +5 because 'g' as +3 and 'a' has the extra "0x" > > The sign + "0x" + "p" + the sign of the exponent also give 5. > > But this assumes that you did not have width and precision fields. > >> Other than that, it feels wrong that this replacement function is still used >> on some windows configurations, visual studio has had vsnprintf for a long >> time now. There is also the possibility of using gnulib's version of >> vsnprintf if we don't want to maintain our own, but I think I'd rather make >> configure fail on missing vsnprintf to force users to configure their >> toolchain properly. > > IIRC, the issue is that the version is MS Windows is buggy. > > This is no longer an issue in MinGW, where __USE_MINGW_ANSI_STDIO > is now defined by default, if I understand correctly. > > GMP's vsnprintf is also used under OpenBSD 7+, which does not > support %n. > > But I would say that it would be OK to consider that broken features > in the system vsnprintf would also affect GMP, as long as they do not > affect the specifiers with GMP types. > > -- > Vincent Lef?vre - Web: > 100% accessible validated (X)HTML - Blog: > Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) > _______________________________________________ > gmp-bugs mailing list > gmp-bugs at gmplib.org > https://gmplib.org/mailman/listinfo/gmp-bugs -- Marc Glisse