From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.devel Subject: Re: bignum branch Date: Wed, 25 Jul 2018 22:02:45 +0100 Message-ID: <8636w758qy.fsf@gmail.com> References: <87o9fbbw1t.fsf@tromey.com> <86in5jdj49.fsf@gmail.com> <83wotxaiwi.fsf@gnu.org> <86k1pxmvmx.fsf@gmail.com> <83efg4a6ie.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1532552466 8438 195.159.176.226 (25 Jul 2018 21:01:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 25 Jul 2018 21:01:06 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (windows-nt) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 25 23:01:02 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 1fiQu6-00026L-GE for ged-emacs-devel@m.gmane.org; Wed, 25 Jul 2018 23:01:02 +0200 Original-Received: from localhost ([::1]:55968 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fiQwD-0008Gb-Cd for ged-emacs-devel@m.gmane.org; Wed, 25 Jul 2018 17:03:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fiQw0-0008F7-7Q for emacs-devel@gnu.org; Wed, 25 Jul 2018 17:03:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fiQvx-00033d-9h for emacs-devel@gnu.org; Wed, 25 Jul 2018 17:03:00 -0400 Original-Received: from [195.159.176.226] (port=34345 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fiQvx-00030y-1p for emacs-devel@gnu.org; Wed, 25 Jul 2018 17:02:57 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1fiQtm-0001iq-VY for emacs-devel@gnu.org; Wed, 25 Jul 2018 23:00:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 45 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:4Nbuyrac29JhLphVMc5P3td/xBA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:227817 Archived-At: On Sun 15 Jul 2018, Eli Zaretskii wrote: >> 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. Indeed - I don't see this being addressed anytime soon. > 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. A quick look at that patch shows that it does not address all of the issues. It fixes problems with large bitwidth numbers, but does not handle other problems where the code assumes that long is not smaller than mp_limb_t. I think we will need to work around this in emacs until a better upstream solution is available. AndyM