From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bignum branch Date: Sun, 15 Jul 2018 18:00:25 +0300 Message-ID: <83efg4a6ie.fsf@gnu.org> References: <87o9fbbw1t.fsf@tromey.com> <86in5jdj49.fsf@gmail.com> <83wotxaiwi.fsf@gnu.org> <86k1pxmvmx.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1531666747 12976 195.159.176.226 (15 Jul 2018 14:59:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Jul 2018 14:59:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andy Moreton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 15 16:59:03 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1feiUI-0003IM-IR for ged-emacs-devel@m.gmane.org; Sun, 15 Jul 2018 16:59:02 +0200 Original-Received: from localhost ([::1]:45837 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1feiWP-0007xf-FC for ged-emacs-devel@m.gmane.org; Sun, 15 Jul 2018 11:01:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37781) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1feiVb-0007x2-7k for emacs-devel@gnu.org; Sun, 15 Jul 2018 11:00:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1feiVY-0003d1-0e for emacs-devel@gnu.org; Sun, 15 Jul 2018 11:00:23 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57975) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1feiVX-0003ce-TR; Sun, 15 Jul 2018 11:00:19 -0400 Original-Received: from [176.228.60.248] (port=4963 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1feiVX-00072a-6j; Sun, 15 Jul 2018 11:00:19 -0400 In-reply-to: <86k1pxmvmx.fsf@gmail.com> (message from Andy Moreton on Sat, 14 Jul 2018 21:04:38 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:227429 Archived-At: > From: Andy Moreton > Date: Sat, 14 Jul 2018 21:04:38 +0100 > > The problem is that if EMACS_INT is "long long", then the calls to > mpz_*_si() API routines will truncate any values passed to GMP. This > means that emacs cannot use any the mpz_*_si() routines directly. Right, I see what you mean now: all those APIs accept 'long' or 'unsigned long' as the integral type. So this is a limitation of GMP as of now. This message: https://gmplib.org/list-archives/gmp-discuss/2016-March/005966.html indicates that GMP developers plan to address this in version 7, but the current master branch of GMP is still on version 6, so I guess it will be a while. Btw, I had a cursory look at the GMP sources, and it seemed to me that changing GMP to lift this limitation should not be too hard. The patch shown in this message: https://gmplib.org/list-archives/gmp-discuss/2016-March/005965.html seems to confirm that. So maybe someone could build GMP with MinGW64 after applying that patch, and if it works, submit the patches to MSYS2 guys so that they could release a fixed library. Then Emacs won't need to jump through these hoops on 64-bit Windows systems.