On Tuesday, 7 July 2020 10:41:39 UTC+1, Benjie Lu wrote:
>
>
> Thank you for your help. I made it. The default visual studio solution
>> will use windows 8.1 sdk, while I work on windows 10 with windows 10 sdk,
>> there is a link error, " can not open file x64\Debug\mpn\add_err1_n.obj " .
>>
On Tuesday, 7 July 2020 06:18:09 UTC+1, Benjie Lu wrote:
>
> Hello , everyone,
> The two zip files : 1. mpir3.0.0 on mpir.org
> 2. mpir-master on
> https://github.com/BrianGladman/mpir
> are diffirent. And the latter seems to be compatible with the
> lates
On Tuesday, 28 April 2020 23:49:09 UTC+1, Cactus wrote:
>
> On 28/04/2020 23:28, 'Bill Hart' via mpir-devel wrote:
> > You may be right, but I don't see where your files are in our repo:
> >
> > https://github.com/wbhart/flint2
> >
> >
On Tuesday, 28 April 2020 23:09:02 UTC+1, Cactus wrote:
>
> On 28/04/2020 22:48, 'Bill Hart' via mpir-devel wrote:
> > They both take about 0.6s with our continuous integration. I don't know
> > if @tthsqe12 would expect them to randomly hit a rea
On Tuesday, 28 April 2020 15:51:06 UTC+1, Cactus wrote:
>
> On 28/04/2020 15:44, 'Bill Hart' via mpir-devel wrote:
>
> > That's great news, thanks Brian.
>
> I fear that I have reported a complete pass too early as I missed the
> fact that my test code h
On Tuesday, 21 April 2020 00:28:28 UTC+1, Bill Hart wrote:
>
> Hi Brian,
>
> After making these changes, our cmake continuous integration fails. I
> think the problem is with this line:
>
> FLINT_DLL const unsigned int partitions_lookup[128];
>
> Is this only relevant for MSVC?
>
> Bill.
>
Good
You have two options if you wish to use MPIR on Windows.
You can use the Linux repository, (https://github.com/wbhart/mpir) in which
case you will need to have cygwin or mingw installed (the 32 or 64 bit
versions or both depending on your needs)
Or you can use the Windows repository (https
On Sunday, 11 August 2019 21:52:40 UTC+1, Russell Wallace wrote:
>
> I've written a Python script that successfully builds MPIR on Windows with
> the Microsoft compiler; in particular, it finds the latest SDK installed,
> and updates the project files to specify that SDK.
>
> https://github.com
I would like to contact Alex Dyachenco (the author of MPIR.NET) as it
needs maintenance in order to work with the current MPIR Windows build.
I would be grateful If Alex (or anyone else who knows his email address)
could ask him to contact me (riemannic at gmail dot com).
Brian Gladman
On Thursday, 2 May 2019 06:17:10 UTC+1, degski wrote:
>
> Good day!
>
> I've been trying to build mpir from repo:
> https://github.com/BrianGladman/mpir .
>
Hi Degski,
Unfortunately I am away at the moment so I am a bit limited in what I can
do to help until Tuesday next week. I have tried
In my MPIR repository at https://github.com/BrianGladman/mpir I have new
Windows assembler code for Intel processors, some new function from GMP
some tidying up of the source code and a major revision of the Windows
build code. Although this can be used directly, a number of people have
asked
On Wednesday, 30 May 2018 22:21:56 UTC+1, Mike Terry wrote:
>
> Hi, I'm new to MPIR, and really am just playing around/familiarising
> myself with what it can do at the moment. My program produced an AV when
> calling mpz_powm with large exp and mod parameters. This seems to be due
> to a mis
On Tuesday, 6 March 2018 10:06:41 UTC, sisyphus wrote:
>
>
>
> -Original Message-
> From: Brian Gladman
> Sent: Tuesday, March 06, 2018 8:39 PM
> To: mpir-...@googlegroups.com
> Subject: Re: [mpir-devel] Re: Can't Compile dll_mpir_gc in VS15
>
> > On 06/03/2018 09:20, sisy...@optusn
On Friday, 2 March 2018 19:06:03 UTC, Oluseye Akomolede wrote:
>
> Good afternoon,
>
> I am getting syntax errors when attempting to compile dll_mpir_gc on
> Visual Studio 2015 community version. I have included a screenshot of the
> error window. I hope that helps. Any help with this would be
On Friday, 2 March 2018 19:06:03 UTC, Oluseye Akomolede wrote:
>
> Good afternoon,
>
> I am getting syntax errors when attempting to compile dll_mpir_gc on
> Visual Studio 2015 community version. I have included a screenshot of the
> error window. I hope that helps. Any help with this would be
I have run into an error in compiling MPFR against MPIR which is caused by
the fact that clz_tab in GMP is now 129 bytes long whereas it is 128 bytes
long in MPIR. It seems that this changed in GMP some time ago but we have
not followed this change. Should we now follow this change?
best re
The issue I am rasing here is Windows x64 specific and does not affect MPIR
on other architectures.
The mpir_ui and mpir_si types were introduced in MPIR to allow all x64
systems (including Windows x64) to handle 64-bit integers as the norm.
This has worked well but recently one incompatibility
a
On Saturday, 7 November 2015 22:50:22 UTC, SeVlaT wrote:
>
> Hi.
>
> This becomes an issue if people don't explicitly specify the libraries
>> that they are going to use. But in our case we explicitly set up the
>> correct libraries for Release and Debug so we don't make any use of the
>> MSP
On Saturday, 21 December 2013 14:47:59 UTC, Rob Bowman wrote:
>
> Hi,
>
> I'm running mpir_config.py to create a specific build target for westmere
> (I chose 23) and I'm getting the error below. Can anyone help me with this
> please? I tried using Python 2.7 and then uninstalled that and used
On Saturday, 21 December 2013 14:47:59 UTC, Rob Bowman wrote:
>
> Hi,
>
> I'm running mpir_config.py to create a specific build target for westmere
> (I chose 23) and I'm getting the error below. Can anyone help me with this
> please? I tried using Python 2.7 and then uninstalled that and used
On Saturday, 21 December 2013 14:47:59 UTC, Rob Bowman wrote:
>
> Hi,
>
> I'm running mpir_config.py to create a specific build target for westmere
> (I chose 23) and I'm getting the error below. Can anyone help me with this
> please? I tried using Python 2.7 and then uninstalled that and used
On Saturday, 21 December 2013 14:47:59 UTC, Rob Bowman wrote:
>
> Hi,
>
> I'm running mpir_config.py to create a specific build target for westmere
> (I chose 23) and I'm getting the error below. Can anyone help me with this
> please? I tried using Python 2.7 and then uninstalled that and used
This is a comment on the item:
use __INTEL_COMPILER instead of INTEL_COMPILER in longlong.inc files
on Bill's list of MPIR ToDo items.
On Linux I believe that the defines for the "Intel compiler version" are __ICC
and __INTEL_COMPILER. On WIndows the define for the "Intel compiler
version" is
I have just committed an update to MPIR's C++ header (mpirxx.h) to bring it
into line with the update that Marc Glisse did for GMP some time ago
(thanks Marc).
While doing this I found an issue with the predefined symbol we use to
detect the Intel compiler - we use INTEL_COMPILER but on Windows
; Are they the only people using these directly?
>
> Bill.
>
> On 26 January 2013 17:15, Cactus > wrote:
> > Some time ago we added mpn_redc_1 and mpn_redc_2 to MPIR and it now
> turns
> > out that GMP 5.1.0 has also added these BUT with different declarations.
&g
Some time ago we added mpn_redc_1 and mpn_redc_2 to MPIR and it now turns
out that GMP 5.1.0 has also added these BUT with different declarations.
The GMP functions each return a carry whereas the MPIR versions do not.
Should we do anything about this?
Brian
--
You received this messa
On Monday, 14 January 2013 22:25:11 UTC, MJ Michaels wrote:
> On Monday, January 14, 2013 4:44:44 PM UTC-5, Cactus wrote:
> > On Monday, 14 January 2013 18:37:16 UTC, MJ Michaels wrote:
> > Is it possible to configure the VC10 build in MPIR 2.6.0 to generate
> 64-bit limbs
On Monday, 14 January 2013 18:37:16 UTC, MJ Michaels wrote:
> Is it possible to configure the VC10 build in MPIR 2.6.0 to generate
> 64-bit limbs? I am able to do this, but have to edit mpir.h by hand to get
> it to work, and I'm wondering if there's just some build option that I'm
> missing.
On Sunday, 25 November 2012 21:25:14 UTC, Bill Hart wrote:
>
> Hi all,
>
> I have just finished creating a Git repository for MPIR on GitHub:
>
> https://github.com/wbhart/mpir
>
> We will be using Git very much like SVN, to simplify things for SVN
> users until they get used to the more adva
I came across this site:
http://www.ospv.com/mpir-and-mpfr/
which seems to be distributing MPIR (and MPFR) in binary form without
giving any references to where the source code can be found.
I may be wrong but it seems to me that this does not comply with our GPL
license.
Does anyone else hav
I have created a patch for GMP-ECM (the SVN version) that allows it to be
built with MPIR-2.6.0 and Bill's New FFT.
A patch giving the changes needed is attached. If you are able to tests
it, please report any successes and failures here.
Brian
--
You received this message because you
On Monday, 15 October 2012 00:43:27 UTC+1, Bill Hart wrote:
>
> Hi all,
>
> I've released MPIR-2.6.0 alpha2 on our website http://mpir.org/
>
> This should fix the issues discovered in the first alpha.
>
> I've tested on a K10-2 and ia64. Any other build reports, test reports
> or results of
As far as I can tell, the Windows command line build relies on a file
(cfg.h) in each of the mpn assembler directories. This file holds a list of
the assembler files in the directory
But there is a potential problem here because these cfg.h files are built
only when the Visual Studio build for
On Thursday, 27 September 2012 16:43:55 UTC+1, Bill Hart wrote:
> More bad news.
>
> The filename
>
> mpir-2.5.1/build.vc10/mpir-tests/fft.fft_ifft_mfa_truncate_sqrt2/fft.fft_ifft_mfa_truncate_sqrt2.vcxproj
>
>
> is apparently too long, so we cannot create a tarball of MPIR.
>
> How do we w
On Saturday, 1 September 2012 12:28:25 UTC+1, Volker Braun wrote:
>
> No I really meant __GMP_MP_RELEASE! Though that might be a good question
> to ask the GMP developers. In any case, see
>
> http://gmplib.org/list-archives/gmp-commit/2010-January/000283.html
>
> for the commit.
>
> That is od
On Monday, 27 August 2012 00:52:32 UTC+1, Volker Braun wrote:
>
> Starting with GMP 5.0.1 the version can also be gotten from the following
> macro in gmp.h (autogenerated from gmp-h.in):
>
> #define __GMP_MP_RELEASE (__GNU_MP_VERSION * 1 +
> __GNU_MP_VERSION_MINOR * 100 + __GNU_MP_VERSION_
> We are probably ready to merge the MPIR-EXP branch into trunk but this
> will mean that there will be a (hopefully) short period during which the
> trunk won't build correctly.
> To minimise this period, it will be necessary to coordinate changes to the
> source code and to Windows Visu
On Sunday, 10 June 2012 19:49:37 UTC+1, Jason Moxham wrote:
>
> On Sunday, 10 June 2012 17:15:09 UTC+1, Jason Moxham wrote:
> >
> >
> > > Hi
> > >
> > > I figured out what going on here , basically configure is failing to
> > > populate config.h with the required
> > > #define HAVE_NATIVE_
On Sunday, 10 June 2012 17:15:09 UTC+1, Jason Moxham wrote:
>
>
> > Hi
> >
> > I figured out what going on here , basically configure is failing to
> > populate config.h with the required
> > #define HAVE_NATIVE_mpn_addmul_2 1
> > and all the others , it has always done this on mingw64 but b
On Tuesday, March 27, 2012 5:38:46 PM UTC+1, michael85 wrote:
>
> Hi Brian,
>
> Thank you for the insightful comments, but your statement regarding the
> code not being suitable for cryptographic use is quite disappointing for
> me. Indeed, it looks discouraging to try and implement the require
On Tuesday, March 27, 2012 2:38:57 PM UTC+1, michael85 wrote:
>
> Hello,
>
> I have started working on a client server system in C++ for privacy
> preserving signal processing applications. Since this system will rely on
> certain public key cryptography primitives, I decided to try and implemen
On Friday, February 24, 2012 5:56:38 AM UTC, inkyvoyd wrote:
>
> Hello,
> My email is \aile\cwu\@gm\ail.co\m (without the backslashes). I also
> only work with Windows because I believe that most parts of Linux are
> much too technical for me to understand. I don't really understand how
> to M
Yes, I can help you via email if you can let me have an email address (or
if you know mine). But I can only help on Windows as I don't use Linux for
development.
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussion
Hello,
Welcome to mpir-devel! The first thing that I can say is that MPIR on its
own is not the best application to use for multiple precision floating
point applications. The mpf functions work but they have now been
superseded by another package called MPFR (see www.mpfr.org) that provides
On Tue, 24 Jan 2012 07:37:09 -0800
Case Van Horsen
> On Tue, Jan 24, 2012 at 5:59 AM, Cactus wrote:
> >> To reinforce that these new types are MPIR specific, should they
> >> be called mpir_ui/mpir_si?
> >
> > I had exactly the same idea a few days ago - I
> To reinforce that these new types are MPIR specific, should they be called
mpir_ui/mpir_si?
I had exactly the same idea a few days ago - I am inclined to do this.
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussi
> To reinforce that these new types are MPIR specific, should they be called
mpir_ui/mpir_si?
I had exactly the same idea a few days ago - I am inclined to go this.
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussi
Hi Case,
I think the ability to build using any of the compilers you mention would
be a good addition. Jason maintains the command line build so the changes
would need to go to him.
MPFR builds with mpir-exp and all tests pass. MPC also builds with
mpir-exp but one test currently fails due
The FFT tuning appears to work in Windows but if I turn on asserts I see
the same problem that Jason reported earlier.
But I don't see the out of memory problem.
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussion
Great work Jason!
I got quite a few of these out of memory issues in my testing of the new
FFT.
It probably occurs when one of the recursive FFT routines is entered with
the length (n) set to zero, which causes an 'infinite' recursion. This (n
== 0) is not supposed to happen.
If you can sen
It is also worth mentioning that the output location has changed if the
version in the SVN is being used.
As you say, the lib and dll output directories used to be subdirectories of
mpir\build.vc10.
But in the SVN (and future versions of MPIR) the output directories lib,
dll and bin are subd
Thanks Jason,
Right now the source code files for the mpn_* routines provide the
interface to the new FFT are in the fft subdirectory.
Does this matter - should I move them to the mpn\generic subdirectory?
I don't expect these to be subject to assembler code overrides but there
may be other
I have corrected a minor bug and made several cosmetic updates to the
MPIR-EXP branch.
If Case can let me have the updates needed for the mpir-exp command line
build, I will add these to the SVN.
The only major outstanding issue (apart from as much application level
testing as possible) is to
Thanks for the testing. You are right - the t-locale.c test failure is not
a major concern.
Has anyone tested a Linux build for the mpir-exp branch?
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussion on the web v
This would be a desirable objective but I have never seen it as feasible
because I get thousands of warnings when I set the maximum warning level.
Going through each of these, analysing them and deciding what to do about
each of them would involve a large amount of work and I doubt that we
eith
Bill found the problem with the FFT code and I have now uploaded the fix to
the mpir-exp branch in the MPIR repository.
This fixes the problem for me but I would be grateful if you could check it
out.
Thanks for helping to test this branch.
Do you have any applications that will exercise t
Thanks Case - I can reproduce the problem and I will do some work on it
with Bill and get a fix as soon as possible.
Is this the only test that fails?
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussion on the web
You are right, the file is not in the SVN.
My apologies for this - I assumed that a file in the SVN could be renamed
and would stay in the SVN but it doesn't seem so.
I've now uploaded it and corrected the other problem you found as well.
Brian
--
You received this message because you
Thanks for trying this Case - I appreciate your efforts.
Unfortunately I don't use Jason's command line build but since it all works
in Visual Studio, I would guess that it must be something missing in this
build.
If it is possible to check all the files that are compiled into the build,
it
For some weeks now I have had an early version of an MPIR for WIndows x64
in which the GMP/MPIR integer interface (the ui/si functions) uses 64-bit
integers rather than the 32-bit longs that would normally be used. This
version is available in the mpir-exp branch of the MPIR subversion
reposit
Bill's new FFT code is now fully integrated into the mpir-exp branch of the
MPIR repository.
It passes all tests but it has not been properly tuned yet.
I have not stripped out the old FFT code and the old and new FFT can be
compared by building MPIR with the define OLD_FFT set if timings for t
I would prefer not to document the python build in this release as it is
only experimental at the moment. The definitive version is the one I am
working on in the mpir-exp directory in SVN and I don't guarantee that the
version in trunk will work..
For the next release I am working on a new Wind
exe!fft_truncate1_twiddle(ii=649f90, is=8, n=0, w=000100, t1=2ef878,
t2=2ef898, ws=1, r=0, c=0, rs=20, trunc=0) Line 113
exe!fft_truncate1_twiddle(ii=649f90, is=8, n=1, w=80, t1=2ef878,
t2=2ef898, ws=1, r=0, c=0, rs=10, trunc=0) Line 123
exe!fft_truncate1_twiddle(ii=649f90, is=8, n=
mul_mfa_truncate_sqrt2(r1=648810, i1=648090, n1=78, i2=648450, n2=78,
depth=7, w=1)
fft_mfa_truncate_sqrt2_outer(ii=649f90, n=80, w=1, t1=2ef878, t2=2ef898,
temp=2ef8b8, n1=8, trunc=100)
fft_truncate1_twiddle(ii=649f90, is=8, n=10, w= 8, t1=2ef878, t2=2ef898,
ws=1, r=0, c=0, rs=1, trunc=0)
fft_t
The twiddle code is entered with n = 0 from the above sequence both when n
= 1 and also when trunk = 0 and n = 0.
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussion on the web visit
https://groups.google.com/d
This is one sequence IN fft_mfa_truncate_sqrt2.c that ends with entry to
the failing code with n = 0.
void fft_truncate1_twiddle(mp_limb_t ** ii, mp_size_t is,
mp_size_t n, mp_bitcnt_t w, mp_limb_t ** t1, mp_limb_t ** t2,
mp_size_t ws, mp_size_t r, mp_size_t c, mp_size_t rs, mp_size_t
I think I have found the problem.
Both fft_radix2_twiddle and ifft_radix2_twiddle don't guard against entry
with n = 0. I changed the first part of both routines according to the
template:
if (n < 2)
{
mp_size_t tw1, tw2;
tw1 = r*c;
tw2 = tw1 + rs*c;
if(n)
I think I have found the problem.
Both ifft_radix2_twiddle and ifft_radix2_twiddle don't guard against entry
with n = 0. I changed the first part of both routines according to the
template:
if (n < 2)
{
mp_size_t tw1, tw2;
tw1 = r*c;
tw2 = tw1 + rs*c;
if(n)
Thanks Bill,
So the test failure matters - I was hoping that it didn't :-)
My laptop, which I am using right now, has 4GB of RAM - I am not clear
whether it is the stack or the heap that overflows but I suspect the former.
On another issue, how do I actually integrate the new FFT with MPIR?
I am using the version you refer to above.
As far as I can see, the test t-mul_mfa_truncate_sqrt2 does end up
calling fft_radix2_twiddle via this call sequence:
mul_mfa_truncate_sqrt2(r1, i1, int_limbs, i2, int_limbs, depth, w);
fft_mfa_truncate_sqrt2_outer(ii, n, w, &t1, &t2, &s1, sqrt,
Only one test now fails:
mul_mfa_truncate_sqrt2
It runs out of memory after a huge number of recursive calls
to fft_radix2_twiddle
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussion on the web visit
https://gr
I think the FLINT64 define is a potential issue.
Should the FFT work with MPIR's longlong.h
What should I do about flint_clz_tab?
I have removed all references to the include file 'ulong_extras.h' - maybe
this is needed somewhere (although everything builds without it)..
Brian
--
You
The split/combine works in win32 so this is, as you suggest, the old 32/64
bit integer problem. I couldn't test the other tow failures in win32 as
they require gmpn_addsub_n which ends up as an undefined symbol in the
32-bit builds that I can use.
I have not yet done the malloc conversions so
I have got the FFT building on Windows but three of the tests fail in x64:
mul_mfa_truncate_sqrt2error in limb 0, ea987380 != aa987380
mul_truncate_sqrt2error in limb 0, ea987380 != aa987380
split/combine_bitsFAIL: Error in limb 2, 1002153456 != 1520
I'm not sure how to debug these as
Fantastic work Bill - it offers a really substantial speed up and is hence
something we should add to MPIR as soon as you feel it is ready.
>From your list of changes needed for moving it into MPIR, it seems that
almost all are search/replace operations - is it always obvious where
TMP_MARK sho
The bug is in your mpir_bincoef subroutine where you use a routine that
returns a double as follows:
ret = mpz_get_d(result);
to set a 64-bit value in ret:
Since a double on Windows has a 53 bit mantissa, this will give wrong
values for 64-bit values with longer bit lengths than this.
If y
I have just found an easy solution for the CRLF issue.
It occurred to me that the SVN automatic translation has to check file
types in order to avoid messing up binary files.
I looked at this and it turns out that the SVN configuration file contains
a list of file extensions that specify whi
Hi David
Thank you for your efforts and for finding the bad declaration _mpq_cmp_ui,
which I will shortly correct in the SVN.
THe CRLF vs LF issue is a nuisance but I don't really know what can be done
about it.
This is not the first time the issue has arisen - Jason and I spent some
time w
Hi Rob,
The need to use this mpir.h version was only a temporary measure, one that
is no longer necessary with the SVN version of mpir-exp.
The Visual Studio build doesn't use the Unix/Linux build infrastructure and
the original mpir-exp version that I supplied via a link did not build
mpir.h
Hi David,
I only support Visual Studio builds so I am afraid that we need someone who
uses the cyggwin/mingw/mingw64 builds to help you with this.
I have just done a fairly major update to mpir-exp in SVN but I don't think
this will help with your problem. For others I do recommend that this
r
I have now added this to the MPIR SVN as the branch mpir-exp (with some
updates).
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/mpir-devel/-/8OC82UM7kMcJ.
To
Jason has kindly put a link to my experimental version of MPIR here:
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/mpir-devel/-/53Zmu_QIfGMJ.
To post to this group, send
I have now got a version of MPIR in which it is possible to set the types
of the integers that are used in all the ui/si functions.
As usual it was harder than I expected to get this to work but it now
passes all the tests on win32 and x64 systems with the integer sizes set to
be equal to the
I can only comment on the MSVC Windows build, for which I believe mpir.h is
identical DLL and static library builds. To double check this I have just
built both and compared the two mpir.h files that were generated.
In fact mpir.h is now identical for win32 and x64 builds as well since I
chan
I have made a change to the Windows MPIR build which avoids the increasing
problem caused by the fact that the include file mpir,h is currently
different for win32 and x64 builds.
This has made it only too easy to use the wrong version with the result
that the build fails or, worse, is wrongl
I pleased it's now working for you. I'm happy to help further if necessary.
Its quite hard to make the whole build process completely automatic and
fully parallel. This would involve a lot of work, which means it probably
won't happen unless someone volunteers to do it.
The IDE build as it is
The "file is being used by another process" message is because several
builds are running at the same time.
If you want to build all the projects, it is safer to configure the IDE not
to use parallel builds.
This should avoid the problem you are seeing.
--
You received this message becaus
Hi Steve,
I have just installed the Visual Studio Developer Preview 11.
Note that, in addition to installing Visual Studio 11, the YASM assembler
-- vsyasm.exe -- has to be copied into the directory holding the VC++
version 11 binaries.
After the automatic upgrade of the version 10 build files
I think it would be useful to find out why GMP_NAIL_BITS is not being
defined. It appears to be because the section I referenced is not being
included when I think it should be.
It would be useful to put the ! marks back in but this won't work because
the file is being generated from gmp-h.in
It looks like the script that creates mpir.h is not working properly.
Do you have something like the following early in mpir.h?
#if ! defined (__GMP_WITHIN_CONFIGURE)
#define __GMP_BITS_PER_MP_LIMB 64
#define GMP_LIMB_BITS 64
#define GMP_NAIL_BITS
We don't provide binaries but you can build MPIR with Visual C++ Express
2010.
However, the VC++ Express installation on its own only provides for 32-bit
(win32) builds.
If you want to build MPIR for native 64-bit Windows (x64), you will also
need to install the Windows 7.1 SDK
Bri
All the Windows x64 MPN assembler code now handles 64-bit integers (this was
not always the case).
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/mpir-devel/-/Ju8pBgZqrNEJ
The issue of 32/64-bit integers on Windows comes up regularly and, after the
recent discussion, I have been wondering if there is a
relatively easy implementation strategy.
Since we already know from 64-bit Unix/Linux distributions that the existing
*_ui and *_si functions work when signed and
You are right - size_t is supposed to be 64-bits on Windows x64. But to get
this behaviour, you have to define _WIN64 during the build process.
I have been caught by this so many times because _WIN64 is supposed to be a
predefined macro, onr that is automatically defined for 64-bit builds.
As you have correctly surmise, solving this requires a full rewrite of about
50 functions in the underlying C library, all of which are written in a way
that will use 32-bit integer types on Windows.
This is a large undertaking and, so far, nobody has been willing to embark
on this. With enoug
Following up my earlier response, size_t on Windows x64 is a 32-bit integer
so the test program you used won't use a 64-bit integer. To obtain 64-bit
integers you can use intmax_t and uintmax_t
I found it easy to add a 64-bit constructor to mpirxx.h (NOT gmpxx.h) and
this program then gives t
This is a well known issue that derives from a fundamental incompatibility
between the data models used by GMP (and MPIR) and Windows x64.
GMP and MPIR use the LP64 model whereas Windows x64 uses the LLP64 model -
in consequence integers and longs on Windows x64 integers are 32-bits
whereas i
Thanks William, I can see this messaage.
I have been checking this issue with three simultaneuos connections, one
through Tor, one through a neigbours IP address and one using my own IP
address.
Only my IP adrees is being blocked so I am pretty confident that the site
has been set up to blo
I had an interesting issue come up yesterday, and I wondered if it impacts
just me or whether others might have the same problem?
I had a colleague visit yesterdday and he was trying to access the
gmplib.org site using my internet connection withoout success.
As I never have any problems ac
Hi Ludo,
It is hard to help you as I am using the latest versions of MPIR, MPFR and
MPFRC++ with Visual Studio 2010.
I am wondering why you have not upgraded from VC++ Express 2005 to VC++
Express 2010?
If it is failing only in the linking step, maybe you have not added mpir.lib
and/or mpf
1 - 100 of 672 matches
Mail list logo
