From user42@zip.com.au Tue Jul 1 00:17:20 2003 From: user42@zip.com.au (Kevin Ryde) Date: Tue, 01 Jul 2003 09:17:20 +1000 Subject: GMP Floating point design vs Fractal applications In-Reply-To: (Jim White's message of "Mon, 30 Jun 2003 13:00:46 +0100") References: Message-ID: <87el1b17gf.fsf@zip.com.au> "White, Jim (ITD)" writes: > > The library of standard mathematical functions is critical > for fractal processing. MPFR apparently will offer this but > at this stage it can't be used in my situation (Win32 > environment, dll-reliant). You should be able to use a mingw mpfr static-linked in your application, with the main gmp as a dll. Might have to build mpfr separately though, not from the main gmp build. Or static link everything and be done. From DTAshley@aol.com Tue Jul 1 04:23:01 2003 From: DTAshley@aol.com (DTAshley@aol.com) Date: Mon, 30 Jun 2003 23:23:01 EDT Subject: Initialise an integer with all bits set to 1. Message-ID: <178.1d08e172.2c325895@aol.com> --part1_178.1d08e172.2c325895_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 6/30/2003 7:05:27 PM Eastern Daylight Time, user42@zip.com.au writes: > "Sisyphus" writes: > > > >At the moment I'm initialising the integer to zero with > >mpz_init2() and then looping through each bit and setting it to 1 with > >mpz_setbit(). > > A value 2^n-1 can be done in the expected way with mpz_set_ui(z,1), > mpz_mul_2exp(z,z,n) and mpz_sub_ui(z,z,1). Should be faster than > mpz_setbit, especially since the latter probably ends up doing > repeated reallocs. Hmmm ... the obvious question is whether this scenario is common enough to make a special function call, something like: mpz_assign_repeating_limb_pattern(mpz_t victim, unsigned long *repeating_pattern_array, unsigned pattern_array_length, unsigned nbits) Y'all get the idea, I'm sure. Dave. --part1_178.1d08e172.2c325895_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable In a message dated 6/30/2003 7:05:27 PM Eastern Daylig= ht Time, user42@zip.com.au writes:

"Sisyphus" <kalinabears@iine= t.net.au> writes:
>
>At the moment I'm initialising the integer to zero with
>mpz_init2() and then looping through each bit and setting it to 1 with >mpz_setbit().

A value 2^n-1 can be done in the expected way with mpz_set_ui(z,1),
mpz_mul_2exp(z,z,n) and mpz_sub_ui(z,z,1).  Should be faster than
mpz_setbit, especially since the latter probably ends up doing
repeated reallocs.


Hmmm ... the obvious question is whether this scenario is common enough to m= ake a special function call, something like:

mpz_assign_repeating_limb_pattern(mpz_t victim, unsigned long *repeating_pat= tern_array, unsigned pattern_array_length, unsigned nbits)

Y'all get the idea, I'm sure.

Dave. --part1_178.1d08e172.2c325895_boundary-- From Jim.White@DEFRA.GSI.GOV.UK Tue Jul 1 10:59:13 2003 From: Jim.White@DEFRA.GSI.GOV.UK (White, Jim (ITD)) Date: Tue, 1 Jul 2003 10:59:13 +0100 Subject: GMP Floating point design vs Fractal applications Message-ID: Kevin Ryde writes: > You should be able to use a mingw mpfr static-linked in your > application, with the main gmp as a dll. Might have to build mpfr > separately though, not from the main gmp build. Or static link > everything and be done. Thanks Kevin. Unfortunately my application is not written in "C" (it's a mix of VisualBasic front-end and PowerBasic DLL's) so I can't link to anything statis. It's got to be a fll. Also, I can't build GMP myself - Unix isn't my "native" development environment at all (sorry!!!) on my PC, and although I have access to Unix Servers (Siemens/Reliant) at work, its "C" compiler isn't recognised by GMP's configure, and I'm not allowed to install anything (such as gcc) on it. Hence my reliance on good people like deltatrinity who have built gmp dll's. But perhaps there is a solution for me after all? I do have a stand-alone "C" compiler/linker for the PC (lcc-win32). Could I simply write a "wrapper" DLL in lcc, which would offer dynamically linked entrypoints for my programs but would itself call the mpfr functions, which would be statically linked to the wrapper dll (using mpfr.lib)? That way, all I would need is an mpfr.lib and mpfr.h. Is this a feasible approach? Regards Jim White From Paul.Zimmermann@loria.fr Tue Jul 1 11:30:03 2003 From: Paul.Zimmermann@loria.fr (Paul Zimmermann) Date: Tue, 1 Jul 2003 12:30:03 +0200 Subject: gmp-discuss digest, Vol 1 #170 - 5 msgs In-Reply-To: <20030701100002.22662.26478.Mailman@b.swox.se> (gmp-discuss-request@swox.com) Message-ID: <200307011030.MAA26948@leibniz.loria.fr> Note: I'd be grateful for input here, from those with knowledge of the MPFR functions, regarding a reasonable guess for Q. sqrt() has asymptotically the same cost O(M(n)) than multiplication, but all other functions (exp, sin, cos, atn) have cost O(M(n) log(n)). You might find on www.mpfr.org/timings-mpfr2001-gmp3.1.1.html some old timings that give you an idea of the ratio exp/mul for example. It is about 40 for 100-digit numbers. We could improve that a lot, by using polynomial approximations for (fixed) small sizes. So I have to wait for the MPFR module to be made available via the GMP DLL itself (and I believe this is not possible at the moment), or as a separate library that calls the GMP dll, but which can itself be easily built (i.e. so I could build a MPFR dll, which would then call the GMP dll). I have to say as a developer of mpfr I don't understand either why mpfr is not fully integrated into gmp... Paul Zimmermann From gerry.lin@db.com Wed Jul 2 11:28:10 2003 From: gerry.lin@db.com (Gerry Lin) Date: Wed, 2 Jul 2003 06:28:10 -0400 Subject: Gerry Lin is out of the office. Message-ID: I will be out of the office starting 07/02/2003 and will not return until 07/07/2003. I will respond to your message when I return. For Franfurt Upload to Bony and MBSRD Upload to dtc pls contact dte help desk +1 212 469 4460 -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From fredericks@tiscali.it Wed Jul 2 15:36:12 2003 From: fredericks@tiscali.it (Federico Alba) Date: Wed, 2 Jul 2003 16:36:12 +0200 Subject: help! Message-ID: <000201c340a7$ab5de780$9b1f1d97@myself> This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C340B8.0CBD7990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I downloaded the gnu mp package.=20 Note that I'm a windows user (windows 2000) While reading documentation, I read that on windows systems, I should = use Unix-Like Tools to build gmp.h on, the only header needed to call = gmp functions (is it true?). Then I decided to download it, but on the mingw site there are too = packages for download. Since I had no idea, I downloaded the "mingw" package, containing all = the packages at the latest release. I installed mingw but I still don't know what I have to do. I did not understand how can I should run "./configure" on my system. ------=_NextPart_000_0005_01C340B8.0CBD7990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
 
I downloaded = the gnu mp=20 package.
Note that = I'm a windows=20 user (windows 2000)
 
While = reading=20 documentation, I read that on windows systems, I should use Unix-Like = Tools to=20 build gmp.h on, the only header needed to call gmp functions (is it=20 true?).
Then I = decided to download=20 it, but on the mingw site there are too packages for = download.
Since I had = no=20 idea, I downloaded the "mingw"  package, containing all the = packages=20 at the latest release.
I installed = mingw but I=20 still don't know what I have to do.
I did not = understand how=20 can I should run "./configure" on my = system.
------=_NextPart_000_0005_01C340B8.0CBD7990-- From kalinabears@iinet.net.au Wed Jul 2 16:10:25 2003 From: kalinabears@iinet.net.au (Sisyphus) Date: Thu, 3 Jul 2003 01:10:25 +1000 Subject: help! References: <000201c340a7$ab5de780$9b1f1d97@myself> Message-ID: <008901c340ac$139b4000$4bb0dccb@sisyphusii330h> ----- Original Message ----- From: "Federico Alba" To: Sent: Thursday, July 03, 2003 12:36 AM Subject: help! Hi I downloaded the gnu mp package. Note that I'm a windows user (windows 2000) While reading documentation, I read that on windows systems, I should use Unix-Like Tools to build gmp.h on, the only header needed to call gmp functions (is it true?). Then I decided to download it, but on the mingw site there are too packages for download. Since I had no idea, I downloaded the "mingw" package, containing all the packages at the latest release. I installed mingw but I still don't know what I have to do. I did not understand how can I should run "./configure" on my system. ----------------------------------------------------- The windows 'cmd.exe' (and 'command.com') shells do not understand './configure'. You need to run it in a shell that *does* understand. I used MSYS (as others have done) - availbale from http://www.mingw.org/msys.shtml . With msys properly configured it was simply a matter of opening the msys shell, cd'ing to the GMP source directory, and running './configure --disable-static --enable-shared' followed by 'make'. Hth. Cheers, Rob From arunachalam narayanaswamy" What happened: i was trying to install gmp in my comp but even though i have a gcc compiler i get a error message when i run ./configure: [root@localhost gmp-4.1.2]# ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets ${MAKE}... yes checking whether to enable maintainer-specific portions of Makefiles... no checking compiler gcc -g -O2 -fomit-frame-pointer ... no checking compiler cc -O ... no configure: error: could not find a working compiler i dont know what to do . please give me a way to install gmp in my comp i have gcc-3.2 ,g++ all of them. how should i change the arguments of CC,CFLAGS,CXX... waiting for ur reply ___________________________________________________ Click below to experience Sooraj R Barjatya's latest offering 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek & Kareena http://www.mpkdh.com From chris.saunders@sympatico.ca Wed Jul 2 20:28:39 2003 From: chris.saunders@sympatico.ca (Chris Saunders) Date: Wed, 2 Jul 2003 15:28:39 -0400 Subject: help! References: <000201c340a7$ab5de780$9b1f1d97@myself> Message-ID: <001101c340d0$2473f420$6dccfea9@mycomputer> This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C340AE.9CED9950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Go back to the MinGW site and look for MSYS. This is a UNIX=3Dlike = shell that will allow you to build GMP on Windows 2000. I have found that although GMP = is fine, the MPFR library doesn't work on Windows. Regards Chris Saunders chris.saunders@sympatico.ca ----- Original Message -----=20 From: Federico Alba=20 To: gmp-discuss@swox.com=20 Sent: Wednesday, July 02, 2003 10:36 AM Subject: help! Hi I downloaded the gnu mp package.=20 Note that I'm a windows user (windows 2000) While reading documentation, I read that on windows systems, I should = use Unix-Like Tools to build gmp.h on, the only header needed to call = gmp functions (is it true?). Then I decided to download it, but on the mingw site there are too = packages for download. Since I had no idea, I downloaded the "mingw" package, containing all = the packages at the latest release. I installed mingw but I still don't know what I have to do. I did not understand how can I should run "./configure" on my system. ------=_NextPart_000_000E_01C340AE.9CED9950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Go back to the MinGW site and look for = MSYS. =20 This is a UNIX=3Dlike shell that will
allow you to build GMP on Windows = 2000.  I=20 have found that although GMP is fine,
the MPFR library doesn't work on=20 Windows.
 
Regards
Chris Saunders
chris.saunders@sympatico.ca
 
----- Original Message -----
From:=20 Federico=20 Alba
Sent: Wednesday, July 02, 2003 = 10:36=20 AM
Subject: help!

Hi
 
I = downloaded the gnu mp=20 package.
Note that = I'm a windows=20 user (windows 2000)
 
While = reading=20 documentation, I read that on windows systems, I should use Unix-Like = Tools to=20 build gmp.h on, the only header needed to call gmp functions (is it=20 true?).
Then I = decided to=20 download it, but on the mingw site there are too packages for=20 download.
Since I = had no=20 idea, I downloaded the "mingw"  package, containing all the = packages=20 at the latest release.
I = installed mingw but I=20 still don't know what I have to do.
I did not = understand how=20 can I should run "./configure" on my=20 system.
------=_NextPart_000_000E_01C340AE.9CED9950-- From yaghani@mac.com Wed Jul 2 22:37:19 2003 From: yaghani@mac.com (Yusuf Abdulghani (Local)) Date: Wed, 2 Jul 2003 14:37:19 -0700 Subject: help me !!!!!!!!! In-Reply-To: <20030702161557.26650.qmail@webmail17.rediffmail.com> Message-ID: <5B85E2E6-ACD5-11D7-A162-0050E4506249@mac.com> do a "which" on gcc and see if it is in your path. use ./configure CC="gcc" use ./configure CC="/usr/bin/gcc" or whatever is your complete path name for gcc. Yusuf On Wednesday, July 2, 2003, at 09:15 AM, arunachalam narayanaswamy wrote: > What happened: > > i was trying to install gmp in my comp but even though i have a > gcc compiler i get a error message when i run ./configure: > > [root@localhost gmp-4.1.2]# ./configure > checking build system type... i686-pc-linux-gnu > checking host system type... i686-pc-linux-gnu > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for gawk... gawk > checking whether make sets ${MAKE}... yes > checking whether to enable maintainer-specific portions of > Makefiles... no > checking compiler gcc -g -O2 -fomit-frame-pointer ... no > checking compiler cc -O ... no > configure: error: could not find a working compiler > > i dont know what to do . > please give me a way to install gmp in my comp > i have gcc-3.2 ,g++ all of them. > > how should i change the arguments of CC,CFLAGS,CXX... > waiting for ur reply > > ___________________________________________________ > Click below to experience Sooraj R Barjatya's latest offering > 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek > & Kareena http://www.mpkdh.com > > _______________________________________________ > gmp-discuss mailing list > gmp-discuss@swox.com > https://gmplib.org/mailman/listinfo/gmp-discuss > Yusuf Abdulghani Architecture and Performance Group Apple Computer 408-974-5100 From user42@zip.com.au Thu Jul 3 00:13:04 2003 From: user42@zip.com.au (Kevin Ryde) Date: Thu, 03 Jul 2003 09:13:04 +1000 Subject: GMP Floating point design vs Fractal applications In-Reply-To: (Jim White's message of "Tue, 1 Jul 2003 10:59:13 +0100") References: Message-ID: <87u1a4ttdq.fsf@zip.com.au> "White, Jim (ITD)" writes: > > Also, I can't build GMP myself - Unix isn't my "native" > development environment at all (sorry!!!) on my PC, and > although I have access to Unix Servers (Siemens/Reliant) > at work, its "C" compiler isn't recognised by GMP's > configure, If it's a normal unix style cc then it ought to work. Make a bug report if you think it should. > But perhaps there is a solution for me after all? I do > have a stand-alone "C" compiler/linker for the PC (lcc-win32). The mingw tools would be your best bet. You might be able to do a static build, and then put the mpfr/*.o objects into a dll. Either the mingw or microsoft tools ought to work for that, I forget the exact commands. From user42@zip.com.au Thu Jul 3 00:00:50 2003 From: user42@zip.com.au (Kevin Ryde) Date: Thu, 03 Jul 2003 09:00:50 +1000 Subject: help me !!!!!!!!! In-Reply-To: <5B85E2E6-ACD5-11D7-A162-0050E4506249@mac.com> (Yusuf Abdulghani's message of "Wed, 2 Jul 2003 14:37:19 -0700") References: <5B85E2E6-ACD5-11D7-A162-0050E4506249@mac.com> Message-ID: <87y8zgtty5.fsf@zip.com.au> "arunachalam narayanaswamy" writes: > > [root@localhost gmp-4.1.2]# ./configure It's usually regarded as a bad idea to compile as root. > checking compiler gcc -g -O2 -fomit-frame-pointer ... no Have a look in the config.log file generated for more about what went wrong. PS. Bug reports belong on bug-gmp@gnu.org, see "Reporting Bugs" in the manual. From chris.saunders@sympatico.ca Thu Jul 3 02:27:37 2003 From: chris.saunders@sympatico.ca (Chris Saunders) Date: Wed, 2 Jul 2003 21:27:37 -0400 Subject: Division of a small number by a larger one References: <87u1a4ttdq.fsf@zip.com.au> Message-ID: <000901c34102$4a1efa30$6dccfea9@mycomputer> If if I use mpf_t's to do division and I divide 1.0 / 10.0 I get the correct answer. If I try 1.0 / 11.0 I get 0.0 no matter how high I set the precision of the numerator. Could there be a problem with the library I built or am I using this type of number incorrectly? Regards Chris Saunders chris.saunders@sympatico.ca From user42@zip.com.au Thu Jul 3 02:36:28 2003 From: user42@zip.com.au (Kevin Ryde) Date: Thu, 03 Jul 2003 11:36:28 +1000 Subject: Division of a small number by a larger one In-Reply-To: <000901c34102$4a1efa30$6dccfea9@mycomputer> (Chris Saunders's message of "Wed, 2 Jul 2003 21:27:37 -0400") References: <87u1a4ttdq.fsf@zip.com.au> <000901c34102$4a1efa30$6dccfea9@mycomputer> Message-ID: <87d6gstmqr.fsf@zip.com.au> "Chris Saunders" writes: > > If if I use mpf_t's to do division and I divide 1.0 / 10.0 I get > the correct answer. If I try 1.0 / 11.0 I get 0.0 Sounds wrong. Make a bug report including a test program. > no matter how high I set the precision of the numerator. It's the precision of the destination which determines the result, but the minimum is 53 bits, so 0 is not right. From chris.saunders@sympatico.ca Thu Jul 3 03:42:07 2003 From: chris.saunders@sympatico.ca (Chris Saunders) Date: Wed, 2 Jul 2003 22:42:07 -0400 Subject: Division of a small number by a larger one References: <87u1a4ttdq.fsf@zip.com.au><000901c34102$4a1efa30$6dccfea9@mycomputer> <87d6gstmqr.fsf@zip.com.au> Message-ID: <004501c3410c$b26bd450$6dccfea9@mycomputer> Thanks for the reply Keven I am not keen to send in a bug report as my situation is a little complicated. What I have done is written code in Eiffel that wraps the code in GMP. I have done this on Windows 2000 and don't think that GMP likes this platform too well - it took me awhile to build a library that would work at all. Part of the problem may be that my Eiffel compiler uses the Microsoft Visual C++ 6.0 compiler as a back end to build the "C" code that the Eiffel compiler generates. I attempted to write some code that wraps the MPFR stuff and it wouldn't work at all. Regards Chris Saunders chris.saunders@sympatico.ca ----- Original Message ----- From: "Kevin Ryde" To: "Chris Saunders" Cc: Sent: Wednesday, July 02, 2003 9:36 PM Subject: Re: Division of a small number by a larger one > "Chris Saunders" writes: > > > > If if I use mpf_t's to do division and I divide 1.0 / 10.0 I get > > the correct answer. If I try 1.0 / 11.0 I get 0.0 > > Sounds wrong. Make a bug report including a test program. > > > no matter how high I set the precision of the numerator. > > It's the precision of the destination which determines the result, but > the minimum is 53 bits, so 0 is not right. > _______________________________________________ > gmp-discuss mailing list > gmp-discuss@swox.com > https://gmplib.org/mailman/listinfo/gmp-discuss > From arunachalam narayanaswamy" hi all, thanx for the mails. but still the problem comes. [root@localhost root]# cd gmp/gmp-4.1.2 [root@localhost gmp-4.1.2]# ./configure CC="/usr/bin/gcc" checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets ${MAKE}... yes checking whether to enable maintainer-specific portions of Makefiles... no checking compiler /usr/bin/gcc -g -O2 -fomit-frame-pointer ... no configure: error: could not find a working compiler *****I checked the config.log file : here it is :****** This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.53. Invocation command line was $ ./configure CC=gcc ## --------- ## ## Platform. ## ## --------- ## hostname = localhost.localdomain uname -m = i686 uname -r = 2.4.18-14 uname -s = Linux uname -v = #1 Wed Sep 4 13:35:50 EDT 2002 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = i686 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /sbin PATH: /bin PATH: /usr/sbin PATH: /usr/bin PATH: /usr/X11R6/bin PATH: /root/bin PATH: . PATH: //root PATH: /root/nedit-5.3/source ## ----------- ## ## Core tests. ## ## ----------- ## configure:1523: checking build system type configure:1541: result: i686-pc-linux-gnu configure:1549: checking host system type configure:1563: result: i686-pc-linux-gnu configure:1593: checking for a BSD-compatible install configure:1647: result: /usr/bin/install -c configure:1658: checking whether build environment is sane configure:1701: result: yes configure:1734: checking for gawk configure:1750: found /bin/gawk configure:1760: result: gawk configure:1770: checking whether make sets ${MAKE} configure:1790: result: yes configure:1941: checking whether to enable maintainer-specific portions of Makefiles configure:1950: result: no configure:1014: User: ABI= CC=gcc CFLAGS=(unset) CPPFLAGS=(unset) MPN_PATH= configure:1020: GMP: abilist=standard cclist=gcc cc configure:3157: gcc 2>&1 | grep xlc >/dev/null configure:3160: $? = 1 configure:3191: checking compiler gcc -g -O2 -fomit-frame-pointer configure:3219: gcc -g -O2 -fomit-frame-pointer conftest.c >&5 gcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. See for instructions. configure:3222: $? = 1 configure:3238: result: no configure:3375: error: could not find a working compiler ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=i686-pc-linux-gnu ac_cv_build_alias=i686-pc-linux-gnu ac_cv_env_ABI_set= ac_cv_env_ABI_value= ac_cv_env_CC_set=set ac_cv_env_CC_value=gcc ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_CXXCPP_set= ac_cv_env_CXXCPP_value= ac_cv_env_CXXFLAGS_set= ac_cv_env_CXXFLAGS_value= ac_cv_env_CXX_set= ac_cv_env_CXX_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_M4_set= ac_cv_env_M4_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_host=i686-pc-linux-gnu ac_cv_host_alias=i686-pc-linux-gnu ac_cv_path_install='/usr/bin/install -c' ac_cv_prog_AWK=gawk ac_cv_prog_make_make_set=yes lt_cv_sys_path_separator=: ## ----------- ## ## confdefs.h. ## ## ----------- ## #define PACKAGE_NAME "" #define PACKAGE_TARNAME "" #define PACKAGE_VERSION "" #define PACKAGE_STRING "" #define PACKAGE_BUGREPORT "" #define HAVE_HOST_CPU_i686 1 #define PACKAGE "gmp" #define VERSION "4.1.2" #define WANT_FFT 1 #define HAVE_HOST_CPU_FAMILY_x86 1 configure: exit 1 help me!!!!!! continues ___________________________________________________ Click below to experience Sooraj R Barjatya's latest offering 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek & Kareena http://www.mpkdh.com From nisse@lysator.liu.se Thu Jul 3 08:11:49 2003 From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 03 Jul 2003 09:11:49 +0200 Subject: still problem!!!!!!!!!! In-Reply-To: <20030703040848.19876.qmail@webmail27.rediffmail.com> References: <20030703040848.19876.qmail@webmail27.rediffmail.com> Message-ID: "arunachalam narayanaswamy" writes: > configure:3219: gcc -g -O2 -fomit-frame-pointer conftest.c >&5 gcc: > Internal error: Segmentation fault (program cc1) Please submit a > full bug report. See for > instructions. Looks like you have found a gcc bug. Or it could also be some local problem in your environment. Or even a hardware problem. It's a little fishy that it is the first compilation configure tries that fails.. Usually, configure dumps the testprogram conftest.c it couldn't compile to config.log, so that you can try to run gcc on it by yourself; I have no idea why that didn't happen here. Have you tested if you can compile a hello world program, using the same flags, -g -O2 -fomit-frame-pointer? If it turns out to be a true gcc bug, please follow the instructions at the mentioned URL for reporting it. If you're using an old version of gcc, you could also try upgrading and see if that helps. /Niels From katrin@pcpool.mathematik.uni-freiburg.de Thu Jul 3 14:09:40 2003 From: katrin@pcpool.mathematik.uni-freiburg.de (Katrin Peter) Date: Thu, 3 Jul 2003 15:09:40 +0200 Subject: probab_prim_p Message-ID: <20030703150940.1826eed1.katrin@pcpool.mathematik.uni-freiburg.de> hi I use your gmp library for a c source code. Iwant to verify the goldbach conjecture between 10^24 and 10^25. For this I use the function mpz_probab_prim_p. Where can I find the implementation for the function and do you know how I can certificate my numbers as prime (not probably prime) I would be very happy to get an answer. thanks katrin peter From arunachalam narayanaswamy" hi all, thanx to all those who replied for my bugging mails.i got the same error for some other things also. so i decided to reinstall gcc . i reinstalled it fully(all of gcc I mean!) and now its working . may be some of my files were corrupt.so i am going to get started on this one only now!!. bye cheers Arunachalam ___________________________________________________ Click below to experience Sooraj R Barjatya's latest offering 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek & Kareena http://www.mpkdh.com From user42@zip.com.au Fri Jul 4 23:45:12 2003 From: user42@zip.com.au (Kevin Ryde) Date: Sat, 05 Jul 2003 08:45:12 +1000 Subject: still problem!!!!!!!!!! In-Reply-To: (Niels =?iso-8859-1?q?M=F6ller's?= message of "03 Jul 2003 09:11:49 +0200") References: <20030703040848.19876.qmail@webmail27.rediffmail.com> Message-ID: <873chlud1j.fsf@zip.com.au> nisse@lysator.liu.se (Niels M=F6ller) writes: > > Usually, configure dumps the testprogram conftest.c it > couldn't compile to config.log, so that you can try to run gcc on it > by yourself; I have no idea why that didn't happen here. It comes from a gmp specific macro. Search for "gcc303" in the configure script for the test code. I'll make it print to config.log for the next release. From user42@zip.com.au Fri Jul 4 23:54:40 2003 From: user42@zip.com.au (Kevin Ryde) Date: Sat, 05 Jul 2003 08:54:40 +1000 Subject: Division of a small number by a larger one In-Reply-To: <004501c3410c$b26bd450$6dccfea9@mycomputer> (Chris Saunders's message of "Wed, 2 Jul 2003 22:42:07 -0400") References: <87u1a4ttdq.fsf@zip.com.au> <000901c34102$4a1efa30$6dccfea9@mycomputer> <87d6gstmqr.fsf@zip.com.au> <004501c3410c$b26bd450$6dccfea9@mycomputer> Message-ID: <87vfuhsy1b.fsf@zip.com.au> "Chris Saunders" writes: > > I have done this on Windows 2000 > and don't think that GMP likes this platform too well - it took > me awhile to build a library that would work at all. cygwin, djgpp and mingw are all supported and should work immediately. > Part of the > problem may be that my Eiffel compiler uses the Microsoft > Visual C++ 6.0 compiler as a back end to build the "C" code > that the Eiffel compiler generates. A native build of gmp with ms c probably doesn't go through, mainly because libtool doesn't know to use ".lib" instead of ".a". From jobey_mcDonaldys@cadvision.com Sat Jul 5 00:44:49 2003 From: jobey_mcDonaldys@cadvision.com (Jobey McDonald) Date: Fri, 04 Jul 2003 23:44:49 +0000 Subject: No introductions needed Message-ID: <3F061171.971768DE@cadvision.com>

"Human Euphoria" cologne

Become more sexually attractive

Get approached more often

Improve business relationships

Meet more people anywhere

Increase your self confidence

Order your supply!





stop receiving futher messages o36rw35xdvfx1 4hypuk1my6jo fu51dd2he0Rk4twkb30445n4s uoj8utjxmo7n1 izmqh13j7dt8gwke2htloda xz1uca1o1066o3R06d7311hhs lstx2416ky dpnk0awuf7

From arunachalam narayanaswamy" hi all, thanx for the help. i dont know whether my previous mail reached u ppl. now i have reinstalled gcc and i am planning to upgrade to redhat9 from 8 so....i got things alright. i will be mailing for help in future i mean in gmp. thanx bye Arunachalam On Sat, 05 Jul 2003 Kevin Ryde wrote : >nisse@lysator.liu.se (Niels Möller) writes: > > > > Usually, configure dumps the testprogram conftest.c it > > couldn't compile to config.log, so that you can try to run gcc >on it > > by yourself; I have no idea why that didn't happen here. > >It comes from a gmp specific macro. Search for "gcc303" in the >configure script for the test code. I'll make it print to >config.log >for the next release. ___________________________________________________ Click below to experience Sooraj R Barjatya's latest offering 'Main Prem Ki Diwani Hoon' starring Hrithik, Abhishek & Kareena http://www.mpkdh.com From chris.saunders@sympatico.ca Sun Jul 6 20:16:31 2003 From: chris.saunders@sympatico.ca (Chris Saunders) Date: Sun, 6 Jul 2003 15:16:31 -0400 Subject: MPFR problems Message-ID: <000501c343f3$1c3dec40$6dccfea9@mycomputer> I have built the GMP library using MinGW using: ./configure --enable-alloca=no --enable-mpfr My situation is that I am writing an interface to GMP using the language Eiffel. My Eiffel compiler builds C code and uses Microsoft Visual C++ 6.0 as the back end C compiler. My platform is Windows 2000. All of GMP works fine but when I try to build the interfaces to certain MPFR functions I get the following error message: libmpfr.a(get_d.o) : error LNK2019: unresolved external symbol __imp___HUGE referenced in function _mpfr_get_d3 gmp.exe : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. Note: The function "mpfr_get_d3" is defined in "get_d.c". This function uses both "MPFR_DBL_INFP" and "MPFR_DBL_INFM". These macros are defined in "mpfr-math.h". They are defined as "HUGE_VAL" and "(-HUGE_VAL)" respectively. I have found 4 library files that contain the text "__imp___HUGE": libcrtdll.a, libmsvcrt.a, libmsvcrt20.a and libmsvcrt40.a If I add any of these libraries to my project the compiler complains about multiply defined symbols. I am hoping to find some help in overcoming this problem. Regards Chris Saunders chris.saunders@sympatico.ca From chris.saunders@sympatico.ca Mon Jul 7 19:45:29 2003 From: chris.saunders@sympatico.ca (Chris Saunders) Date: Mon, 7 Jul 2003 14:45:29 -0400 Subject: MPFR problems Message-ID: <001901c344b7$f3ea2c20$6dccfea9@mycomputer> I have built the GMP library using MinGW using: ./configure --enable-alloca=no --enable-mpfr My situation is that I am writing an interface to GMP using the language Eiffel. My Eiffel compiler builds C code and uses Microsoft Visual C++ 6.0 as the back end C compiler. My platform is Windows 2000. All of GMP works fine but when I try to build the interfaces to certain MPFR functions I get the following error message: libmpfr.a(get_d.o) : error LNK2019: unresolved external symbol __imp___HUGE referenced in function _mpfr_get_d3 gmp.exe : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. Note: The function "mpfr_get_d3" is defined in "get_d.c". This function uses both "MPFR_DBL_INFP" and "MPFR_DBL_INFM". These macros are defined in "mpfr-math.h". They are defined as "HUGE_VAL" and "(-HUGE_VAL)" respectively. I have found 4 library files that contain the text "__imp___HUGE": libcrtdll.a, libmsvcrt.a, libmsvcrt20.a and libmsvcrt40.a If I add any of these libraries to my project the compiler complains about multiply defined symbols. I am hoping to find some help in overcoming this problem. Regards Chris Saunders chris.saunders@sympatico.ca From user42@zip.com.au Tue Jul 8 00:31:00 2003 From: user42@zip.com.au (Kevin Ryde) Date: Tue, 08 Jul 2003 09:31:00 +1000 Subject: MPFR problems In-Reply-To: <000501c343f3$1c3dec40$6dccfea9@mycomputer> (Chris Saunders's message of "Sun, 6 Jul 2003 15:16:31 -0400") References: <000501c343f3$1c3dec40$6dccfea9@mycomputer> Message-ID: <87vfudlxsb.fsf@zip.com.au> "Chris Saunders" writes: > > libmpfr.a(get_d.o) : error LNK2019: unresolved external symbol __imp___HUGE > referenced in function _mpfr_get_d3 mingw math.h claims HUGE should be in msvcrt.dll. > The function "mpfr_get_d3" is defined in "get_d.c". This function > uses both "MPFR_DBL_INFP" and "MPFR_DBL_INFM". You might be able to change them to 1.0/0.0 and -1.0/0.0 respectively, I think gcc is happy with such expressions. The current mpfr cvs (see www.mpfr.org) has changed to use byte sequences for those values, you might like to try that, though you'll need some development tools to build from cvs, eg. autoconf, automake, texinfo. From chris.saunders@sympatico.ca Tue Jul 8 02:34:49 2003 From: chris.saunders@sympatico.ca (Chris Saunders) Date: Mon, 7 Jul 2003 21:34:49 -0400 Subject: MPFR problems References: <000501c343f3$1c3dec40$6dccfea9@mycomputer> <87vfudlxsb.fsf@zip.com.au> Message-ID: <001401c344f1$234de360$6dccfea9@mycomputer> Thanks for the reply Kevin and sorry if I sent you some emails personally. I generally attempt to send all correspondence to the group but I sometimes press the "Reply" rather than the "Reply All" button in error. Earlier today I was working on this and addid this code to the end of the file "mpfr-math.h": #undef MPFR_DBL_NAN #undef MPFR_DBL_INFP #undef MPFR_DBL_INFM double CJS_ONE_CJS = 1.0; double CJS_ZERO_CJS = 0.0; #define MPFR_DBL_NAN (CJS_ZERO_CJS / CJS_ZERO_CJS) #define MPFR_DBL_INFP (CJS_ONE_CJS / CJS_ZERO_CJS) #define MPFR_DBL_INFM (-CJS_ONE_CJS / CJS_ZERO_CJS) I rebuilt the library with MinGW and although I haven't been able to test it very extensively yet, it all seems to be working fine in my Eiffel code now. Regards Chris Saunders chris.saunders@sympatico.ca ----- Original Message ----- From: "Kevin Ryde" To: "Chris Saunders" Cc: Sent: Monday, July 07, 2003 7:31 PM Subject: Re: MPFR problems > "Chris Saunders" writes: > > > > libmpfr.a(get_d.o) : error LNK2019: unresolved external symbol __imp___HUGE > > referenced in function _mpfr_get_d3 > > mingw math.h claims HUGE should be in msvcrt.dll. > > > The function "mpfr_get_d3" is defined in "get_d.c". This function > > uses both "MPFR_DBL_INFP" and "MPFR_DBL_INFM". > > You might be able to change them to 1.0/0.0 and -1.0/0.0 respectively, > I think gcc is happy with such expressions. > > The current mpfr cvs (see www.mpfr.org) has changed to use byte > sequences for those values, you might like to try that, though you'll > need some development tools to build from cvs, eg. autoconf, automake, > texinfo. > _______________________________________________ > gmp-discuss mailing list > gmp-discuss@swox.com > https://gmplib.org/mailman/listinfo/gmp-discuss > From mellisa.peterson_hz@pandora.be Wed Jul 9 21:14:08 2003 From: mellisa.peterson_hz@pandora.be (Mellisa Peterson) Date: Wed, 09 Jul 2003 20:14:08 +0000 Subject: How are you doing ? Message-ID: <3F0C7790.258C157B@pandora.be> From user42@zip.com.au Wed Jul 9 22:44:34 2003 From: user42@zip.com.au (Kevin Ryde) Date: Thu, 10 Jul 2003 07:44:34 +1000 Subject: Initialise an integer with all bits set to 1. In-Reply-To: <178.1d08e172.2c325895@aol.com> (DTAshley@aol.com's message of "Mon, 30 Jun 2003 23:23:01 EDT") References: <178.1d08e172.2c325895@aol.com> Message-ID: <874r1vtlx9.fsf@zip.com.au> DTAshley@aol.com writes: > > mpz_assign_repeating_limb_pattern(mpz_t victim, unsigned long > *repeating_pattern_array, unsigned pattern_array_length, unsigned nbits) Probably better to take the pattern from another mpz than a ulong array. Maybe some sort of bit-block copy from one mpz to another, perhaps with a repetition count, would find a use. From dorais@gauss.dartmouth.edu Thu Jul 10 19:58:57 2003 From: dorais@gauss.dartmouth.edu (Francois G. Dorais) Date: Thu, 10 Jul 2003 14:58:57 -0400 (EDT) Subject: Vector Operations Message-ID: I was wondering if there has ever been interest in adding optimized basic vector operations to gmp. It seems to me that the performance of vector operations on mp types could be greatly improved by low level optimizations especially on vector and other parallel architectures. Surely something like an optimized BLAS implementation for mpf/mpfr would be interesting for those who use these types extensively. I for one would appreciate similar routines for mpz and maybe mpq. A direct translation of BLAS wouldn't be very appropriate for mpz and mpq since since stability considerations are very different, but something very similar would do. However, it may be that the design of such optimized routines is not as "straightforward" as for the basic types because of the greater variety of architectural considerations to take care of? It could also be that such extensions don't fit in the "spirit" of gmp for some reason or another? In any case, I would like to hear what people have to say on the interest and feasibility of such extensions to the gmp family. Thanks, F. G. Dorais From darryl_barneski@caramail.com Fri Jul 11 05:29:12 2003 From: darryl_barneski@caramail.com (Darryl Barnes) Date: Fri, 11 Jul 2003 04:29:12 +0000 Subject: Did I bother you? Message-ID: <3F0E3D18.7EA3A778@caramail.com>

Get Viagra online Now !

We are the cheapest supplier on the net
100 % guarantee !
at 3 $ a dose, try it now. Click here






Discontinue receiving offers 4wha8cv4r1pwkdj13bghxkt2 c1tr95mntqyo z8ajgu2fdhc1j2bbmlddajnm1vygknw8e3o mgadf12hojxcg2 ahlzvca9pdv3l41co53w7r9lj

From mbardiaux@peaktime.be Fri Jul 11 10:02:14 2003 From: mbardiaux@peaktime.be (Michel Bardiaux) Date: Fri, 11 Jul 2003 11:02:14 +0200 Subject: Vector Operations References: Message-ID: <3F0E7D16.1060902@peaktime.be> Francois G. Dorais wrote: > I was wondering if there has ever been interest in adding optimized basic > vector operations to gmp. It seems to me that the performance of vector > operations on mp types could be greatly improved by low level > optimizations especially on vector and other parallel architectures. > > Surely something like an optimized BLAS implementation for mpf/mpfr > would be interesting for those who use these types extensively. I for one > would appreciate similar routines for mpz and maybe mpq. A direct > translation of BLAS wouldn't be very appropriate for mpz and mpq since > since stability considerations are very different, but something very > similar would do. > > However, it may be that the design of such optimized routines is not as > "straightforward" as for the basic types because of the greater variety of > architectural considerations to take care of? It could also be that such > extensions don't fit in the "spirit" of gmp for some reason or another? > > In any case, I would like to hear what people have to say on the interest > and feasibility of such extensions to the gmp family. > > Thanks, > F. G. Dorais > I'm no expert on the internals of gmp, but it seems to me efficient vectorization/parallelization would be possible only if all components of the vectors have the same number of limbs. Am I correct? -- Michel Bardiaux Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles Tel : +32 2 790.29.41 From j.l.moxham@maths.soton.ac.uk Sat Jul 12 21:13:53 2003 From: j.l.moxham@maths.soton.ac.uk (Jason Moxham) Date: Sat, 12 Jul 2003 21:13:53 +0100 Subject: faster modular arithmetic? Message-ID: <200307122113.53193.j.l.moxham@maths.soton.ac.uk> very roughly... ( we rely on a*b mod 2^k+-1 is faster than a*b mod 2^k is faster than a*b) given a fixed modulas m we wish to calculate x%m for many x using typical barrett method(simplified) one off part choose R1,R2 such that 3<=m<=x0 while( r > m) r=r-m // loop at most twice then r=x%m where normally we choose R1=2^n=R2/2 for some suitible n (depending on our x's) clearly a modular reduction in this case can be done with two full multiplications , as is well known step 1 and 2 amount to a high part and low part multiplication which are faster than a full mul but only for small sizes(say <4000 limbs) by changing R2=2^(n+1)+1 or R2=2^(n+1)-1 , then we still get the same result but we can calculate q*m%R2 faster than q*m , for the plus case use gmp FFT mod 2^k+1 , and for minus case we use modular multiplication(like Knuth(factorize R2)) Of course n,k have to be chosen carefully , but experiments seem to indicate that a preliminary version of this is faster than a well optimized high/low part barrett division for a "largish" range of limb sizes ? can we calculate floor(Inv*x/(2^k+-1)) faster than a high part mul (which is faster than a mul) for some ranges The same approach applys to Montgomery reduction (simplified) but here R1 must be equal to R2 test gcd(m,R1)==1 let Inv= -m^-1 mod R1 1)let q=x*Inv%R1 2)let r=(x+m*q)/R2 // exact div (as R1==R2) if r>m then r=r-m then r==xR1^-1 mod m typically we use R1=2^n for suitible n and so get step 1 to be a low part mul and step 2 to be a high part mul (+1 if R2|x) as above we can change R1 to 2^n+-1 , and this can speed up step 1 (faster than lowpart mul) a few problems remain , how to test gcd(m,2^n+1 or 2^n-1)=1 fast ? ( may not be too important at the sizes where x*m%(2^n+1) is faster than x*m%2^n ) exact div by 2^n+1 is easy , but can we get a faster verision ie calculate x+m*q/R2 directly rather than use a full mul ( eg like when R2=2^n then we can use a high half mul) perhaps something like if r<2^n then (x+m*q)/(2^n+1)= (x+m*q)%2^n = r ( so can use a low part mul) Its all bit sketchy , but it seems promising enough to continue jason From j.l.moxham@maths.soton.ac.uk Sun Jul 13 10:10:38 2003 From: j.l.moxham@maths.soton.ac.uk (Jason Moxham) Date: Sun, 13 Jul 2003 10:10:38 +0100 Subject: faster modular arithmetic? In-Reply-To: <3F10AA82.4040109@netscape.net> References: <200307122113.53193.j.l.moxham@maths.soton.ac.uk> <3F10AA82.4040109@netscape.net> Message-ID: <200307131010.38557.j.l.moxham@maths.soton.ac.uk> On Sunday 13 Jul 2003 01:40, you wrote: > Jason, > The attached paper of mine may interest you. > Phil McLaughlin > Thanks , I had heard of it , and was curious what was in it . Next week I plan to code up the barrett version , hopefully it will show some nice speedups , I will read your paper for the montgomery version and I will first have to finish the "standard/subquad" version for something to compair against. From j.l.moxham@maths.soton.ac.uk Sun Jul 13 10:28:07 2003 From: j.l.moxham@maths.soton.ac.uk (Jason Moxham) Date: Sun, 13 Jul 2003 10:28:07 +0100 Subject: mul_fft.c Message-ID: <200307131028.07682.j.l.moxham@maths.soton.ac.uk> looking at mpn/generic/mul_fft.c its not entirely clear how to call a "mpn_mul_mod_2^k+1"(mp_ptr dest,mp_srcptr src1,mp_srcptr src2,mp_size_t k) // dest= src1*src2 % 2^(k*GMP_NUMB_BITS)+1 any hints ? thanks jason From Steven.Potter@comcast.net Mon Jul 14 05:02:02 2003 From: Steven.Potter@comcast.net (Steven Potter) Date: Sun, 13 Jul 2003 21:02:02 -0700 Subject: Random Numbers Message-ID: <274132527419b3.27419b32741325@icomcast.net> Hello, I have a question in regards to utilizing the random number generators with GMP. I've read over the manual and I'm still stumped as to how to initialize, and use the random number generating functions. The way I understand it is I call gmp_randinit_default() and pass in some parameter, which I can't find any documentation on, (perhaps I skipped it somewhere), then I call one of the mpz_random functions to get a number correct? Could anyone give me a code snippet of how to properly initialize and obtain a random number with GMP. I'm trying to get a random number for some cryptographic software I'm working on for school. Thanks, Steven Potter From ECFLaw@ntu.edu.sg Mon Jul 14 06:27:44 2003 From: ECFLaw@ntu.edu.sg (Law Chong Fatt) Date: Mon, 14 Jul 2003 13:27:44 +0800 Subject: gmp-4.1.2 installation Message-ID: SGksDQogDQpJJ20gaW5zdGFsbGluZyBnbXAtNC4xLjIgd2l0aDoNCiANCmMtY29tcHBpbGVyOiBn Y2MtMy4zDQpvczogc29sYXJpcyAyLjcNCmNwdTogc3BhcmN2OQ0KIA0KRHVyaW5nIG1ha2UgKHdo aWxlIGNvbXBpbGluZyBhc3ByaW50Zl8uYyksIHRoZSBmb2xsb3dpbmcgZXJyIGFwcGVhcmVkOg0K IA0KZ2NjIC1ESEFWRV9DT05GSUdfSCAtSS4gLUkuIC1JLi4gLURfX0dNUF9XSVRISU5fR01QIC1J Li4gLWcgLU8yIC1XYSwteGFyY2g9djhwbHVzIC1tY3B1PXVsdHJhc3BhcmMgLWMgYXNwcmludGZf LmMgLW8gYXNwcmludGZfLm8NCg0KYXNwcmludGYuYzoyMjoyMzogd2FybmluZzogZXh0cmEgdG9r ZW5zIGF0IGVuZCBvZiAjbGluZSBkaXJlY3RpdmUNCg0KLi4vY29uZmlnLmg6MToyMzogd2Fybmlu ZzogZXh0cmEgdG9rZW5zIGF0IGVuZCBvZiAjbGluZSBkaXJlY3RpdmUNCg0KYXNwcmludGYuYzoy NTo3Njogd2FybmluZzogZXh0cmEgdG9rZW5zIGF0IGVuZCBvZiAjbGluZSBkaXJlY3RpdmUNCg0K L3Vzci9sb2NhbC9saWIvZ2NjLWxpYi9zcGFyYy1zdW4tc29sYXJpczIuNi8zLjMvaW5jbHVkZS9z dGRhcmcuaDoxOjc3OiB3YXJuaW5nOiBleHRyYSB0b2tlbnMgYXQgZW5kIG9mICNsaW5lIGRpcmVj dGl2ZQ0KDQovdXNyL2xvY2FsL2xpYi9nY2MtbGliL3NwYXJjLXN1bi1zb2xhcmlzMi42LzMuMy9p bmNsdWRlL3N0ZGFyZy5oOjQ0Ojc3OiB3YXJuaW5nOiBleHRyYSB0b2tlbnMgYXQgZW5kIG9mICNs aW5lIGRpcmVjdGl2ZQ0KDQovdXNyL2xvY2FsL2xpYi9nY2MtbGliL3NwYXJjLXN1bi1zb2xhcmlz Mi42LzMuMy9pbmNsdWRlL3N0ZGFyZy5oOjg2OjIzOiB3YXJuaW5nOiBleHRyYSB0b2tlbnMgYXQg ZW5kIG9mICNsaW5lIGRpcmVjdGl2ZQ0KDQphc3ByaW50Zi5jOjMwOjIwOiB3YXJuaW5nOiBleHRy YSB0b2tlbnMgYXQgZW5kIG9mICNsaW5lIGRpcmVjdGl2ZQ0KDQouLi9nbXAuaDo1NDo3Njogd2Fy bmluZzogZXh0cmEgdG9rZW5zIGF0IGVuZCBvZiAjbGluZSBkaXJlY3RpdmUNCg0KL3Vzci9sb2Nh bC9saWIvZ2NjLWxpYi9zcGFyYy1zdW4tc29sYXJpczIuNi8zLjMvaW5jbHVkZS9zdGRkZWYuaDox Ojc4OiB3YXJuaW5nOiBleHRyYSB0b2tlbnMgYXQgZW5kIG9mICNsaW5lIGRpcmVjdGl2ZQ0KDQov dXNyL2xvY2FsL2xpYi9nY2MtbGliL3NwYXJjLXN1bi1zb2xhcmlzMi42LzMuMy9pbmNsdWRlL3N0 ZGRlZi5oOjIxNDoyMTogd2FybmluZzogZXh0cmEgdG9rZW5zIGF0IGVuZCBvZiAjbGluZSBkaXJl Y3RpdmUNCg0KLi4vZ21wLmg6MjExNToyMzogd2FybmluZzogZXh0cmEgdG9rZW5zIGF0IGVuZCBv ZiAjbGluZSBkaXJlY3RpdmUNCg0KYXNwcmludGYuYzozMToyNTogd2FybmluZzogZXh0cmEgdG9r ZW5zIGF0IGVuZCBvZiAjbGluZSBkaXJlY3RpdmUNCg0KLi4vZ21wLWltcGwuaDozODoyMzogd2Fy bmluZzogZXh0cmEgdG9rZW5zIGF0IGVuZCBvZiAjbGluZSBkaXJlY3RpdmUNCg0KLi4vY29uZmln Lmg6MToyNjogd2FybmluZzogZXh0cmEgdG9rZW5zIGF0IGVuZCBvZiAjbGluZSBkaXJlY3RpdmUN Cg0KLi4vZ21wLWltcGwuaDozOToyNzogd2FybmluZzogZXh0cmEgdG9rZW5zIGF0IGVuZCBvZiAj bGluZSBkaXJlY3RpdmUNCg0KLi4vZ21wLW1wYXJhbS5oOjE6MjY6IHdhcm5pbmc6IGV4dHJhIHRv a2VucyBhdCBlbmQgb2YgI2xpbmUgZGlyZWN0aXZlDQoNCi4uL2dtcC1pbXBsLmg6MjkzNDoyMzog d2FybmluZzogZXh0cmEgdG9rZW5zIGF0IGVuZCBvZiAjbGluZSBkaXJlY3RpdmUNCg0KYXNwcmlu dGYuYzogSW4gZnVuY3Rpb24gYF9fZ21wX2FzcHJpbnRmJzoNCg0KYXNwcmludGYuYzozNjogZXJy b3I6IHBhcnNlIGVycm9yIGJlZm9yZSAidmFfZGNsIg0KDQphc3ByaW50Zi5jOjM2OiBlcnJvcjog bnVtYmVyIG9mIGFyZ3VtZW50cyBkb2Vzbid0IG1hdGNoIHByb3RvdHlwZQ0KDQouLi9nbXAuaDo1 MDM6IGVycm9yOiBwcm90b3R5cGUgZGVjbGFyYXRpb24NCg0KYXNwcmludGYuYzo0Njogd2Fybmlu Zzogc2Vjb25kIHBhcmFtZXRlciBvZiBgdmFfc3RhcnQnIG5vdCBsYXN0IG5hbWVkIGFyZ3VtZW50 DQoNCm1ha2VbMl06ICoqKiBbYXNwcmludGZfLmxvXSBFcnJvciAxDQoNCm1ha2VbMl06IExlYXZp bmcgZGlyZWN0b3J5IGAvaG9tZS9jZmxhdy90b29scy9nbXAtNC4xLjIvcHJpbnRmJw0KDQptYWtl WzFdOiAqKiogW2FsbC1yZWN1cnNpdmVdIEVycm9yIDENCg0KbWFrZVsxXTogTGVhdmluZyBkaXJl Y3RvcnkgYC9ob21lL2NmbGF3L3Rvb2xzL2dtcC00LjEuMicNCg0KbWFrZTogKioqIFthbGxdIEVy cm9yIDINCg0KQ291bGQgc29tZW9uZSBwcm92aWRlIHNvbWUgYWR2aWNlPw0KDQpUaGFua3MuDQoN ClJlZ2FyZHMsDQoNCkxhdyBDaG9uZyBGYXR0DQoNCg== From igor@txc.com Mon Jul 14 06:34:32 2003 From: igor@txc.com (Igor Schein) Date: Mon, 14 Jul 2003 01:34:32 -0400 Subject: gmp-4.1.2 installation In-Reply-To: References: Message-ID: <20030714053432.GK24143@txc.com> On Mon, Jul 14, 2003 at 01:27:44PM +0800, Law Chong Fatt wrote: > Hi, > > I'm installing gmp-4.1.2 with: > > c-comppiler: gcc-3.3 > os: solaris 2.7 > cpu: sparcv9 > > During make (while compiling asprintf_.c), the following err appeared: > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -g -O2 -Wa,-xarch=v8plus -mcpu=ultrasparc -c asprintf_.c -o asprintf_.o sparcv9 means 64bit, yet -xarch=v8plus indicates 32bit. Which one do you expect to build? Igor From pggimeno@wanadoo.es Mon Jul 14 18:23:17 2003 From: pggimeno@wanadoo.es (pggimeno@wanadoo.es) Date: Mon, 14 Jul 2003 19:23:17 +0200 Subject: Random Numbers In-Reply-To: <274132527419b3.27419b32741325@icomcast.net> References: <274132527419b3.27419b32741325@icomcast.net> Message-ID: <6lp5hvs45o23dd3r6khddmbmkb183shqpq@4ax.com> Steven Potter wrote: >I have a question in regards to utilizing the random number generators=20 >with GMP. I've read over the manual and I'm still stumped as to how to=20 >initialize, and use the random number generating functions. The way I=20 See http://www.swox.com/list-archives/gmp/2002-July/000762.html N.B. The MIME encoding is not interpreted in the HTML page above, thus the '=3D3D' should be replaced by a '=3D'. HTH --=20 Pedro Gimeno From user42@zip.com.au Tue Jul 15 00:46:04 2003 From: user42@zip.com.au (Kevin Ryde) Date: Tue, 15 Jul 2003 09:46:04 +1000 Subject: gmp-4.1.2 installation In-Reply-To: <20030714053432.GK24143@txc.com> (Igor Schein's message of "Mon, 14 Jul 2003 01:34:32 -0400") References: <20030714053432.GK24143@txc.com> Message-ID: <87u19ozn7n.fsf@zip.com.au> Igor Schein writes: > > sparcv9 means 64bit, No, in gmp sparcv9 represents an ISA. On solaris it can run in either 32 or 64 bit ABI. See ABI and ISA in the manual. From user42@zip.com.au Tue Jul 15 00:52:35 2003 From: user42@zip.com.au (Kevin Ryde) Date: Tue, 15 Jul 2003 09:52:35 +1000 Subject: gmp-4.1.2 installation In-Reply-To: (Law Chong Fatt's message of "Mon, 14 Jul 2003 13:27:44 +0800") References: Message-ID: <87ptkczmws.fsf@zip.com.au> "Law Chong Fatt" writes: > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -g -O2 -Wa,-xarch=v8plus -mcpu=ultrasparc -c asprintf_.c -o asprintf_.o It seems configure has decided to use the ansi2knr stuff, which of course is not required for gcc. Look for the "ANSI" tests reported in config.log to see if you can tell what went wrong. Otherwise post that file, and the output of the configure. > asprintf.c:22:23: warning: extra tokens at end of #line directive Don't know what's wrong with the output of ansi2knr that it provokes this, it should work, even though its transformations are not required and not wanted. PS. All bug reports to bug-gmp, as stated in the manual. From igor@txc.com Tue Jul 15 00:54:35 2003 From: igor@txc.com (Igor Schein) Date: Mon, 14 Jul 2003 19:54:35 -0400 Subject: gmp-4.1.2 installation In-Reply-To: <87u19ozn7n.fsf@zip.com.au> References: <20030714053432.GK24143@txc.com> <87u19ozn7n.fsf@zip.com.au> Message-ID: <20030714235435.GV24143@txc.com> On Tue, Jul 15, 2003 at 09:46:04AM +1000, Kevin Ryde wrote: > Igor Schein writes: > > > > sparcv9 means 64bit, > > No, in gmp sparcv9 represents an ISA. On solaris it can run in either > 32 or 64 bit ABI. See ABI and ISA in the manual. That's a bit inconsistent with the normal Solaris notations: % isainfo sparcv9 sparc 64bit and 32bit respectively. Also, Sun cc uses -xarch=v9 to compile 64bit binaries. So that's what I meant in the previous email. Igor From user42@zip.com.au Tue Jul 15 01:42:55 2003 From: user42@zip.com.au (Kevin Ryde) Date: Tue, 15 Jul 2003 10:42:55 +1000 Subject: gmp-4.1.2 installation In-Reply-To: <20030714235435.GV24143@txc.com> (Igor Schein's message of "Mon, 14 Jul 2003 19:54:35 -0400") References: <20030714053432.GK24143@txc.com> <87u19ozn7n.fsf@zip.com.au> <20030714235435.GV24143@txc.com> Message-ID: <87smp8y60g.fsf@zip.com.au> Igor Schein writes: > > That's a bit inconsistent with the normal Solaris notations: Oh, well, their names are not a model of clarity. v9 is really an arch not an abi, and v8plus for v9 running 32-bits is especially confusing to the uninitiated. In any case we use the cpu part of the config tuple to indicate a cpu type, and keep notions of abi separate. This makes it easy to introduce exact cpu names, like ultrasparc2i or whatever. From felix.klee.gmp@gmx.net Tue Jul 15 23:19:53 2003 From: felix.klee.gmp@gmx.net (Felix E. Klee) Date: Wed, 16 Jul 2003 00:19:53 +0200 Subject: Specifying precision in vector? Message-ID: <200307160019.53166.felix.klee.gmp@gmx.net> Hi, what's the easiest way to create a std::vector of mpf_class with a certain precision PREC (which is not the default precision)? I tried subclassing mpf_class but as explained in the online help this leads to much trouble because one has to redefine many operators. If there's no easy way: Has someone considered adding the precision as a template parameter? That way one could write "std::vector > some_vector". Felix -- To contact me in private don't reply but send mail to felix DOT klee AT inka DOT de From user42@zip.com.au Wed Jul 16 00:12:43 2003 From: user42@zip.com.au (Kevin Ryde) Date: Wed, 16 Jul 2003 09:12:43 +1000 Subject: gmp-4.1.2 installation In-Reply-To: (Law Chong Fatt's message of "Tue, 15 Jul 2003 10:58:28 +0800") References: Message-ID: <87brvvl6z8.fsf@zip.com.au> "Law Chong Fatt" writes: > > configure:4105: gcc -c -g -O2 -Wa,-xarch=v8plus -mcpu=ultrasparc conftest.c >&5 > In file included from configure:4060: > /usr/include/sys/stat.h:253: error: parse error before "blksize_t" > /usr/include/sys/stat.h:257: error: parse error before '}' token > /usr/include/sys/stat.h:313: error: parse error before "blksize_t" > /usr/include/sys/stat.h:314: error: conflicting types for `st_blocks' > /usr/include/sys/stat.h:254: error: previous declaration of `st_blocks' > /usr/include/sys/stat.h:317: error: parse error before '}' token > configure:4108: $? = 1 > configure: failed program was: > #line 4056 "configure" > #include "confdefs.h" > #include > #include > #include > #include > ... Looks like there's something dodgy in sys/stat.h. Perhaps you can find where blksize_t is meant to come from. I'd have expected it to be either in types.h, or stat.h itself. Perhaps the "stat" man page says otherwise. Either way, this test is part of autoconf, so a problem here probably affects all gnu packages in one way or another, not just gmp. From user42@zip.com.au Wed Jul 16 00:46:41 2003 From: user42@zip.com.au (Kevin Ryde) Date: Wed, 16 Jul 2003 09:46:41 +1000 Subject: Specifying precision in vector? In-Reply-To: <200307160019.53166.felix.klee.gmp@gmx.net> (Felix E. Klee's message of "Wed, 16 Jul 2003 00:19:53 +0200") References: <200307160019.53166.felix.klee.gmp@gmx.net> Message-ID: <873ch7l5em.fsf@zip.com.au> "Felix E. Klee" writes: > > what's the easiest way to create a std::vector of mpf_class with a certain > precision PREC (which is not the default precision)? I tried subclassing > mpf_class but as explained in the online help this leads to much trouble > because one has to redefine many operators. It'd be nice if we could make that easier. > If there's no easy way: Has someone considered adding the precision as a > template parameter? That way one could write "std::vector > > some_vector". I'm not up with how vector works, but can you specify a constructor call for the elements? That'd allow you to put a precision there. (Cc'ed to Gerardo for his input.) From user42@zip.com.au Wed Jul 16 00:54:17 2003 From: user42@zip.com.au (Kevin Ryde) Date: Wed, 16 Jul 2003 09:54:17 +1000 Subject: mul_fft.c In-Reply-To: <200307131028.07682.j.l.moxham@maths.soton.ac.uk> (Jason Moxham's message of "Sun, 13 Jul 2003 10:28:07 +0100") References: <200307131028.07682.j.l.moxham@maths.soton.ac.uk> Message-ID: <87y8yzjqhi.fsf@zip.com.au> Jason Moxham writes: > > looking at mpn/generic/mul_fft.c its not entirely clear how to call a > "mpn_mul_mod_2^k+1"(mp_ptr dest,mp_srcptr src1,mp_srcptr src2,mp_size_t k) > // dest= src1*src2 % 2^(k*GMP_NUMB_BITS)+1 I think mpn_mul_fft is the entrypoint, it sets {op,pl} to {n,nl} * {m,ml} modulo 2^{pl*GMP_NUMB_BITS}, or something like that. pl needs to be one of the permitted fft lengths, ie. already padded out to a suitable size for the given k parameter. In tune/speed.h, SPEED_ROUTINE_MPN_MUL_FFT_CALL is a sample call (it ignores the return from mpn_mul_fft, that being the high bit of the result, or something like that). From ECFLaw@ntu.edu.sg Wed Jul 16 04:49:08 2003 From: ECFLaw@ntu.edu.sg (Law Chong Fatt) Date: Wed, 16 Jul 2003 11:49:08 +0800 Subject: gmp-4.1.2 installation Message-ID: SGkgS2V2aW4sDQogDQpUaGFua3MgZm9yIHRoZSBhZHZpY2UuDQogDQpibGtzaXplX3QgaXMgZGVm aW5lZCBpbiAidHlwZXMuaCIgYXM6DQogDQojaWZkZWYgX0xQNjQNCnR5cGVkZWYgaW50ICAgICAg ICAgICAgIGJsa3NpemVfdDsgICAgICAvKiB1c2VkIGZvciBibG9jayBzaXplcyAqLw0KI2Vsc2UN CnR5cGVkZWYgbG9uZyAgICAgICAgICAgIGJsa3NpemVfdDsgICAgICAvKiB1c2VkIGZvciBibG9j ayBzaXplcyAqLw0KI2VuZGlmDQogDQphbmQgaXMgdXNlZCBpbiAic3RhdC5oIiBhcyBhIHR5cGUg Zm9yIHN0X2Jsa3NpemUuDQogDQpBcyB5b3UndmUgc2FpZCwgdGhpcyBpcyBwcm9iYWJseSBhIHBy b2JsZW0gdGhhdCBpcyBub3Qgc3BlY2lmaWNhbGx5IHJlbGF0ZWQgdG8gZ21wLiBCdXQgSSdkIGFw cHJlY2lhdGUgaXQgaWYgeW91IHdvdWxkIGdpdmUgbWUgc29tZSBhZHZpY2Ugb24gaG93IHRvIHJl c29sdmUgaXQuDQogDQpNYW55IHRoYW5rcy4NCiANClJlZ2FyZHMsDQpDaG9uZyBGYXR0DQoNCgkt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBLZXZpbiBSeWRlIFttYWlsdG86dXNl cjQyQHppcC5jb20uYXVdIA0KCVNlbnQ6IFdlZCA3LzE2LzIwMDMgNzoxMiBBTSANCglUbzogTGF3 IENob25nIEZhdHQgDQoJQ2M6IGdtcC1kaXNjdXNzQHN3b3guY29tIA0KCVN1YmplY3Q6IFJlOiBn bXAtNC4xLjIgaW5zdGFsbGF0aW9uDQoJDQoJDQoNCgkiTGF3IENob25nIEZhdHQiIDxFQ0ZMYXdA bnR1LmVkdS5zZz4gd3JpdGVzOg0KCT4NCgk+IGNvbmZpZ3VyZTo0MTA1OiBnY2MgIC1jIC1nIC1P MiAtV2EsLXhhcmNoPXY4cGx1cyAtbWNwdT11bHRyYXNwYXJjICBjb25mdGVzdC5jID4mNQ0KCT4g SW4gZmlsZSBpbmNsdWRlZCBmcm9tIGNvbmZpZ3VyZTo0MDYwOg0KCT4gL3Vzci9pbmNsdWRlL3N5 cy9zdGF0Lmg6MjUzOiBlcnJvcjogcGFyc2UgZXJyb3IgYmVmb3JlICJibGtzaXplX3QiDQoJPiAv dXNyL2luY2x1ZGUvc3lzL3N0YXQuaDoyNTc6IGVycm9yOiBwYXJzZSBlcnJvciBiZWZvcmUgJ30n IHRva2VuDQoJPiAvdXNyL2luY2x1ZGUvc3lzL3N0YXQuaDozMTM6IGVycm9yOiBwYXJzZSBlcnJv ciBiZWZvcmUgImJsa3NpemVfdCINCgk+IC91c3IvaW5jbHVkZS9zeXMvc3RhdC5oOjMxNDogZXJy b3I6IGNvbmZsaWN0aW5nIHR5cGVzIGZvciBgc3RfYmxvY2tzJw0KCT4gL3Vzci9pbmNsdWRlL3N5 cy9zdGF0Lmg6MjU0OiBlcnJvcjogcHJldmlvdXMgZGVjbGFyYXRpb24gb2YgYHN0X2Jsb2NrcycN Cgk+IC91c3IvaW5jbHVkZS9zeXMvc3RhdC5oOjMxNzogZXJyb3I6IHBhcnNlIGVycm9yIGJlZm9y ZSAnfScgdG9rZW4NCgk+IGNvbmZpZ3VyZTo0MTA4OiAkPyA9IDENCgk+IGNvbmZpZ3VyZTogZmFp bGVkIHByb2dyYW0gd2FzOg0KCT4gI2xpbmUgNDA1NiAiY29uZmlndXJlIg0KCT4gI2luY2x1ZGUg ImNvbmZkZWZzLmgiDQoJPiAjaW5jbHVkZSA8c3RkYXJnLmg+DQoJPiAjaW5jbHVkZSA8c3RkaW8u aD4NCgk+ICNpbmNsdWRlIDxzeXMvdHlwZXMuaD4NCgk+ICNpbmNsdWRlIDxzeXMvc3RhdC5oPg0K CT4gLi4uDQoJDQoJTG9va3MgbGlrZSB0aGVyZSdzIHNvbWV0aGluZyBkb2RneSBpbiBzeXMvc3Rh dC5oLiAgUGVyaGFwcyB5b3UgY2FuDQoJZmluZCB3aGVyZSBibGtzaXplX3QgaXMgbWVhbnQgdG8g Y29tZSBmcm9tLiAgSSdkIGhhdmUgZXhwZWN0ZWQgaXQgdG8NCgliZSBlaXRoZXIgaW4gdHlwZXMu aCwgb3Igc3RhdC5oIGl0c2VsZi4gIFBlcmhhcHMgdGhlICJzdGF0IiBtYW4gcGFnZQ0KCXNheXMg b3RoZXJ3aXNlLg0KCQ0KCUVpdGhlciB3YXksIHRoaXMgdGVzdCBpcyBwYXJ0IG9mIGF1dG9jb25m LCBzbyBhIHByb2JsZW0gaGVyZSBwcm9iYWJseQ0KCWFmZmVjdHMgYWxsIGdudSBwYWNrYWdlcyBp biBvbmUgd2F5IG9yIGFub3RoZXIsIG5vdCBqdXN0IGdtcC4NCgkNCgkNCg0K From gerardo.ballabio@unimib.it Wed Jul 16 09:29:05 2003 From: gerardo.ballabio@unimib.it (Ballabio Gerardo - Dip. di Scienza dei Materiali) Date: Wed, 16 Jul 2003 10:29:05 +0200 Subject: Specifying precision in vector? In-Reply-To: <873ch7l5em.fsf@zip.com.au>; from user42@zip.com.au on Wed, Jul 16, 2003 at 01:46:41 +0200 References: <200307160019.53166.felix.klee.gmp@gmx.net> <873ch7l5em.fsf@zip.com.au> Message-ID: <20030716082905.GA9725@nettunio.mater.unimib.it> On 2003.07.16 01:46, Kevin Ryde wrote: > "Felix E. Klee" writes: > > what's the easiest way to create a std::vector of mpf_class with a > certain precision PREC (which is not the default precision)? It's very easy, the constructor: template std::vector::vector(size_type n, const T &value); creates a std::vector with n elements, each of which is a copy of value. Thus, to have a vector of mpf_class with precision PREC, just declare: std::vector v(n, mpf_class(0, PREC)); > If there's no easy way: Has someone considered adding the > precision as a template parameter? That way one could write > "std::vector > some_vector". I did consider that when I started coding gmpxx.h, but at that time g++ couldn't handle it (I guess it was g++ 2.91, or maybe g++ 2.8). Current g++ probably can (I haven't tried), but I doubt that it would be definitely better than how it is done now. (But if you can show me why it's better, I'm willing to reconsider it.) Gerardo From felix.klee.gmp@gmx.net Wed Jul 16 09:38:24 2003 From: felix.klee.gmp@gmx.net (Felix E. Klee) Date: Wed, 16 Jul 2003 10:38:24 +0200 Subject: Specifying precision in vector? In-Reply-To: <873ch7l5em.fsf@zip.com.au> References: <200307160019.53166.felix.klee.gmp@gmx.net> <873ch7l5em.fsf@zip.com.au> Message-ID: <200307161038.24768.felix.klee.gmp@gmx.net> On Wednesday 16 July 2003 01:46, Kevin Ryde wrote: > > what's the easiest way to create a std::vector of mpf_class with a > > certain precision PREC (which is not the default precision)? I tried > > subclassing mpf_class but as explained in the online help this leads to > > much trouble because one has to redefine many operators. > > It'd be nice if we could make that easier. > > > If there's no easy way: Has someone considered adding the precision as > > a template parameter? That way one could write > > "std::vector > some_vector". > > I'm not up with how vector works, but can you specify a constructor > call for the elements? That'd allow you to put a precision there. Ah, yes you can specify a default value and then all elements are initialized with the copy constructor. I didn't think about this solution when I wrote the message. So, the issue seems to be closed for me. However, it might still be nice to be able to specify the precision as a template parameter since then one could write stuff like typedef mpf_class<128> very_long_double; Felix -- To contact me in private don't reply but send mail to felix DOT klee AT inka DOT de From felix.klee.gmp@gmx.net Wed Jul 16 09:49:36 2003 From: felix.klee.gmp@gmx.net (Felix E. Klee) Date: Wed, 16 Jul 2003 10:49:36 +0200 Subject: Specifying precision in vector? In-Reply-To: <20030716082905.GA9725@nettunio.mater.unimib.it> References: <200307160019.53166.felix.klee.gmp@gmx.net> <873ch7l5em.fsf@zip.com.au> <20030716082905.GA9725@nettunio.mater.unimib.it> Message-ID: <200307161049.36205.felix.klee.gmp@gmx.net> On Wednesday 16 July 2003 10:29, Ballabio Gerardo - Dip. di Scienza dei Materiali wrote: > > If there's no easy way: Has someone considered adding the > > precision as a template parameter? That way one could write > > "std::vector > some_vector". > > I did consider that when I started coding gmpxx.h, but at that time > g++ couldn't handle it (I guess it was g++ 2.91, or maybe g++ 2.8). > Current g++ probably can (I haven't tried), but I doubt that it would > be definitely better than how it is done now. (But if you can show me > why it's better, I'm willing to reconsider it.) As I wrote in my reply to Kevin's message, one could use template parameters to define new types like "very_long_double". Although I don't see any technical advantages over the current solution, this feature would IMHO make programs more readable. Felix -- To contact me in private don't reply but send mail to felix DOT klee AT inka DOT de From felix.klee.gmp@gmx.net Wed Jul 16 10:13:51 2003 From: felix.klee.gmp@gmx.net (Felix E. Klee) Date: Wed, 16 Jul 2003 11:13:51 +0200 Subject: Specifying precision in vector? In-Reply-To: <200307161049.36205.felix.klee.gmp@gmx.net> References: <200307160019.53166.felix.klee.gmp@gmx.net> <20030716082905.GA9725@nettunio.mater.unimib.it> <200307161049.36205.felix.klee.gmp@gmx.net> Message-ID: <200307161113.51453.felix.klee.gmp@gmx.net> On Wednesday 16 July 2003 10:49, Felix E. Klee wrote: > > > If there's no easy way: Has someone considered adding the > > > precision as a template parameter? That way one could write > > > "std::vector > some_vector". > > > > I did consider that when I started coding gmpxx.h, but at that time > > g++ couldn't handle it (I guess it was g++ 2.91, or maybe g++ 2.8). > > Current g++ probably can (I haven't tried), but I doubt that it would > > be definitely better than how it is done now. (But if you can show me > > why it's better, I'm willing to reconsider it.) > > As I wrote in my reply to Kevin's message, one could use template > parameters to define new types like "very_long_double". Although I don't > see any technical advantages over the current solution, this feature > would IMHO make programs more readable. I just found something that seems to be possible only with template parameters: mpf_class x[100]; BTW, template parameters seem to be supported fine by newer versions of gcc. The little program below compiles and executes fine with gcc 3.3 which is part of my SuSE 8.2 installation: #include using namespace std; template class a { public: void out() { cout << prec << endl; } }; int main() { a<3> x; x.out(); return 0; } Felix -- To contact me in private don't reply but send mail to felix DOT klee AT inka DOT de From Jim.White@DEFRA.GSI.GOV.UK Wed Jul 16 11:14:22 2003 From: Jim.White@DEFRA.GSI.GOV.UK (White, Jim (ITD)) Date: Wed, 16 Jul 2003 11:14:22 +0100 Subject: Multiple GMP builds - "make" options? Message-ID: I'm using MinGW on a PC to build GMP shared libraries. I build one version (e.g. for cpu type "pentium4") with no problems. Then I try to rebuild another version (e.g. for cpu type "athlon"), so I rerun "configure" with the new cpu type. But when I execute the "make" command nothing gets recompiled! It just produces a series of messages of the form "Nothing to do in ...". How can I specify that I really do want everything recompiled/rebuilt?? Cheers Jim WHite From gerardo.ballabio@unimib.it Wed Jul 16 13:22:40 2003 From: gerardo.ballabio@unimib.it (Ballabio Gerardo - Dip. di Scienza dei Materiali) Date: Wed, 16 Jul 2003 14:22:40 +0200 Subject: Specifying precision in vector? In-Reply-To: <200307161113.51453.felix.klee.gmp@gmx.net>; from felix.klee.gmp@gmx.net on Wed, Jul 16, 2003 at 11:13:51 +0200 References: <200307160019.53166.felix.klee.gmp@gmx.net> <20030716082905.GA9725@nettunio.mater.unimib.it> <200307161049.36205.felix.klee.gmp@gmx.net> <200307161113.51453.felix.klee.gmp@gmx.net> Message-ID: <20030716122240.GA10164@nettunio.mater.unimib.it> On 2003.07.16 11:13, Felix E. Klee wrote: > I just found something that seems to be possible only with template > parameters: > > mpf_class x[100]; Good point. I believe it can be done with unsigned old_prec = mpf_get_default_prec(); mpf_set_default_prec(PREC); mpf_class x[100]; mpf_set_default_prec(old_prec); but I acknowledge that your one-liner is considerably more elegant (and thread-safe). However, using C-style arrays should be discouraged in C++, the "true C++ way" is to use the appropriate standard container instead. > BTW, template parameters seem to be supported fine by newer > versions of gcc. > The little program below compiles and executes fine with gcc 3.3 I used to get issues in particular when trying to mix mpf_classes of different precision, the problem being that with the template approach, you must anticipate the precision of the result, like this: template class c; template c<(N>M)?N:M> operator+(const c &c1, const c &c2); I've just tested this and indeed, it works with g++ 3.0.4, but not with 2.95.4 (Debian stable). However Debian is to my knowledge the only current distribution still based on a pre-3.0 compiler (and "current" and "Debian" may be regarded as mutually exclusive words), so this might be fine. A possible difficulty with templates is that we'd lose the possibility to resize an mpf_class, and in particular it would be impossible to declare an mpf_class without knowing in advance what we want its size to be. But probably this is something that will occur very rarely. Another point is that by design, we wanted mpf_class to be a very lightweight wrapper to mpf_t with no extra functionality (for this reason we've had a rather strong dispute about whether mpq_class should canonicalize its input), and the template approach seems to depart from that. (Kevin, Torbjorn, what do you think?) Anyway, I'll try and look at it, but I'm currently working on a couple of other things, so I can't guarantee that you'll see anything very soon. Gerardo From Jim.White@DEFRA.GSI.GOV.UK Wed Jul 16 14:10:19 2003 From: Jim.White@DEFRA.GSI.GOV.UK (White, Jim (ITD)) Date: Wed, 16 Jul 2003 14:10:19 +0100 Subject: Building a shared library (dll) for MPFR Message-ID: A Win32 dll version of gmp is easily built on a PC under MinGW, but the current build system does not allow for mpfr to be incorporated in the gmp dll. It builds a static library (libmpfr.a) regardless of the gmp build type. MPFR is officially "still in development", so I imagine that in the future the gmp build system will probably be upgraded to incorporate the mpfr entrypoints when building gmp as a shared library. But meanwhile, a separate Win32 dll for MPFR can easily be built (at least, by MinGW users!) 1. Build "libgmp-3.dll" ======================= In MinGW (MSYS shell emulator) a shared version of gmp is built as follows (thanks to deltatrinity for this method) :- ./configure --enable-shared --disable-static --build=$CPU-pc-mingw32 where $CPU is your target cpu type (e.g. "i386", "pentium4", etc) To get MPFR capability included you need an additional configure option :- --enable-mpfr After running configure, issue a "make" command and you will get "libgmp-3.dll" created in directory ./libs. As I mentioned above, currently the mpfr entry points are NOT included in libgmp-3.dll. The system simply builds a static library "libmpfr.a" in the ./mpfr directory. We don't need "libmpfr.a" itself, but we'll use the compiled object files that were used to build it, plus the gmp shared library we've built, to create a shared "libmpfr.dll". 2. Build "libmpfr.dll" ======================= We build a shared version of MPFR as follows :- cd ../mpfr gcc -shared -o libmpfr.dll *.o ../.libs/libgmp-3.dll This creates libmpfr.dll, which should be copied into the same installation directory as libgmp-3.dll. 3. Warning to VB users ======================= Like libgmp-3 itself, the libmpfr.dll uses "cdecl" calling conventions so cannot be used directly from VB, but this is not a major problem as a simple interlude dll can be built to accept "stdcall" function calls from the application and make the corresponding "cdecl" calls to libmpfr.dll. Cheers Jim White Systems Programmer ITD(A)E, SPS Devt Team * 01483 403978 * Jim.White@defra.gsi.gov.uk H A410, Epsom Road, Guildford GU12LD From deltatrinity@hotmail.com Wed Jul 16 14:28:20 2003 From: deltatrinity@hotmail.com (delta trinity) Date: Wed, 16 Jul 2003 09:28:20 -0400 Subject: Multiple GMP builds - "make" options? Message-ID: This is because when you first run 'Make', it create a lot of objects files. If you change the options later, you need to start-up with a fresh GMP, else, gcc won't re-compile the files since it find the already compiled object files. I find it easier to flush the whold GMP directory and de-pack it again from the .tar.gz than deleting each object files individually. Eric >From: "White, Jim (ITD)" >To: "'gmp-discuss@swox.com'" >Subject: Multiple GMP builds - "make" options? >Date: Wed, 16 Jul 2003 11:14:22 +0100 > > >I'm using MinGW on a PC to build GMP shared libraries. > >I build one version (e.g. for cpu type "pentium4") with >no problems. > >Then I try to rebuild another version (e.g. for cpu type "athlon"), >so I rerun "configure" with the new cpu type. > >But when I execute the "make" command nothing gets recompiled! >It just produces a series of messages of the form >"Nothing to do in ...". > >How can I specify that I really do want everything >recompiled/rebuilt?? > > >Cheers > >Jim WHite > > >_______________________________________________ >gmp-discuss mailing list >gmp-discuss@swox.com >https://gmplib.org/mailman/listinfo/gmp-discuss _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From felix.klee.gmp@gmx.net Wed Jul 16 18:15:11 2003 From: felix.klee.gmp@gmx.net (Felix E. Klee) Date: Wed, 16 Jul 2003 19:15:11 +0200 Subject: Specifying precision in vector? In-Reply-To: <20030716122240.GA10164@nettunio.mater.unimib.it> References: <200307160019.53166.felix.klee.gmp@gmx.net> <200307161113.51453.felix.klee.gmp@gmx.net> <20030716122240.GA10164@nettunio.mater.unimib.it> Message-ID: <200307161915.11517.felix.klee.gmp@gmx.net> On Wednesday 16 July 2003 14:22, Ballabio Gerardo - Dip. di Scienza dei Materiali wrote: > I used to get issues in particular when trying to mix mpf_classes of > different precision, the problem being that with the template > approach, you must anticipate the precision of the result, like this: > > template class c; > > template > c<(N>M)?N:M> operator+(const c &c1, const c &c2); > > I've just tested this and indeed, it works with g++ 3.0.4, but not > with 2.95.4 (Debian stable). However Debian is to my knowledge the > only current distribution still based on a pre-3.0 compiler (and > "current" and "Debian" may be regarded as mutually exclusive words), > so this might be fine. > > A possible difficulty with templates is that we'd lose the > possibility to resize an mpf_class, and in particular it would be > impossible to declare an mpf_class without knowing in advance what we > want its size to be. But probably this is something that will occur > very rarely. Thanks for outlining the problems in the template approach. They convince me that changing the status quo is probably the best idea. BTW, I'm fine with the vector solution (it was stupid of me that I didn't think about it at first) and I really don't need to define arrays. I made up the array example because you asked me to show you why the template approach is better (which, again, it probably isn't). Felix -- To contact me in private don't reply but send mail to felix DOT klee AT inka DOT de From la2macph@math.uwaterloo.ca Thu Jul 17 21:43:14 2003 From: la2macph@math.uwaterloo.ca (Lesley MacPherson) Date: Thu, 17 Jul 2003 16:43:14 -0400 (EDT) Subject: GMP dll for windows: linking errors Message-ID: I am trying to build a GMP dll for use in Windows. I am following the instructions at http://home.in.tum.de/~drost/old/howto-compile-gmp-with-vcpp.html (which are for GMP-4.0.1). I am using GMP-4.1.2 and have had to make a few minor changes in order to get the code to compile. Everything is fine till I get to the linking stage, where I get a few unresolved external symbol errors for _vsnprintf, _snprintf, _strnlen, and __imp__MessageBoxA@16. At least two of these (_vsnprintf and _snprintf) are supposed to be in libc.lib, which is included in my project workspace. I used cygwin to generate the gmp.h and config.h files as described on the link above. I have heard of people using MinGW instead. Any thoughts on which is better (cygwin or MinGW) and instructions on how to create a dll using MinGW? Thanks, Lesley From felix.klee.gmp@gmx.net Thu Jul 17 21:48:51 2003 From: felix.klee.gmp@gmx.net (Felix E. Klee) Date: Thu, 17 Jul 2003 22:48:51 +0200 Subject: Specifying precision in vector? In-Reply-To: <200307161915.11517.felix.klee.gmp@gmx.net> References: <200307160019.53166.felix.klee.gmp@gmx.net> <20030716122240.GA10164@nettunio.mater.unimib.it> <200307161915.11517.felix.klee.gmp@gmx.net> Message-ID: <200307172248.51023.felix.klee.gmp@gmx.net> On Wednesday 16 July 2003 19:15, Felix E. Klee wrote: > Thanks for outlining the problems in the template approach. They convince > me that changing the status quo is probably the best idea. Uh, oh, I meant to say "They convince me that *not* changing the status quo is probably the best idea". Felix -- To contact me in private don't reply but send mail to felix DOT klee AT inka DOT de From user42@zip.com.au Thu Jul 17 23:05:10 2003 From: user42@zip.com.au (Kevin Ryde) Date: Fri, 18 Jul 2003 08:05:10 +1000 Subject: GMP dll for windows: linking errors In-Reply-To: (Lesley MacPherson's message of "Thu, 17 Jul 2003 16:43:14 -0400 (EDT)") References: Message-ID: <873ch44xnt.fsf@zip.com.au> Lesley MacPherson writes: > > Everything is fine till I get to the linking stage, where I get a few > unresolved external symbol errors for _vsnprintf, _snprintf, _strnlen, and > __imp__MessageBoxA@16. At least two of these (_vsnprintf and _snprintf) > are supposed to be in libc.lib, which is included in my project workspace. vsnprintf and snprintf might have an extra "_" in the library, mingw headers have a bit of an inline to get that added. strnlen is apparently not in the basic ms runtime, according to mingw. If you ensure HAVE_STRNLEN in the gmp config.h is not defined then it won't be used. Dunno what MessageBoxA is. > I used cygwin to generate the gmp.h and config.h files as described on the > link above. I have heard of people using MinGW instead. Any thoughts on > which is better (cygwin or MinGW) and instructions on how to create a dll > using MinGW? mingw is a lot closer to the bare bones ms stuff than cygwin. Perhaps for instance cygwin has strnlen where mingw doesn't. I'd expect more joy from mingw. From user42@zip.com.au Fri Jul 18 02:52:15 2003 From: user42@zip.com.au (Kevin Ryde) Date: Fri, 18 Jul 2003 11:52:15 +1000 Subject: gmp-4.1.2 installation In-Reply-To: (Law Chong Fatt's message of "Wed, 16 Jul 2003 11:49:08 +0800") References: Message-ID: <87y8ywzjn4.fsf@zip.com.au> "Law Chong Fatt" writes: > > blksize_t is defined in "types.h" Sounds like it should be right. Perhaps you're hitting something other than that types.h. "gcc -E" on a little C file will show exactly where it looks and what it expands to. From Jim.White@DEFRA.GSI.GOV.UK Fri Jul 18 11:37:53 2003 From: Jim.White@DEFRA.GSI.GOV.UK (White, Jim (ITD)) Date: Fri, 18 Jul 2003 11:37:53 +0100 Subject: GMP dll for windows Message-ID: > 17 Jul 2003 16:43:14 -0400 (EDT) > From: Lesley MacPherson > > Any thoughts on which is better (cygwin or MinGW) and instructions > on how to create a dll using MinGW? deltatrinity has shown that building a Win32 dll is really simple under MinGW, and I recommend it: ./configure --enable-shared --disable-static --build=$CPU-pc-mingw32 (where $CPU = i386, pentium4, etc) Then just execute "make" and you'll get "libgmp-3.dll" created in ./.libs Remember the "cdecl" calling convention needs to be used when calling the dll. Cheers Jim White Systems Programmer ITD(A)E, SPS Devt Team * 01483 403978 * Jim.White@defra.gsi.gov.uk H A410, Epsom Road, Guildford GU12LD From kalinabears@iinet.net.au Fri Jul 18 14:34:05 2003 From: kalinabears@iinet.net.au (Sisyphus) Date: Fri, 18 Jul 2003 23:34:05 +1000 Subject: GMP dll for windows: linking errors References: Message-ID: <00ac01c34d31$54dece10$1eb0dccb@sisyphusii330h> ----- Original Message ----- From: "Lesley MacPherson" >instructions on how to create a dll > using MinGW? > You can do it in an MSYS shell - available from http://www.mingw.org/msys.shtml . With msys properly configured it's simply a matter of opening the msys shell, cd'ing to the GMP source directory, and running './configure --disable-static --enable-shared' followed by 'make'. Hth. Cheers, Rob From user42@zip.com.au Sat Jul 19 02:54:02 2003 From: user42@zip.com.au (Kevin Ryde) Date: Sat, 19 Jul 2003 11:54:02 +1000 Subject: Specifying precision in vector? In-Reply-To: <20030716122240.GA10164@nettunio.mater.unimib.it> (Ballabio Gerardo's message of "Wed, 16 Jul 2003 14:22:40 +0200") References: <200307160019.53166.felix.klee.gmp@gmx.net> <20030716082905.GA9725@nettunio.mater.unimib.it> <200307161049.36205.felix.klee.gmp@gmx.net> <200307161113.51453.felix.klee.gmp@gmx.net> <20030716122240.GA10164@nettunio.mater.unimib.it> Message-ID: <87y8yv5lj9.fsf@zip.com.au> gerardo.ballabio@unimib.it (Ballabio Gerardo - Dip. di Scienza dei Materiali) writes: > > Another point is that by design, we wanted mpf_class to be a very > lightweight wrapper to mpf_t with no extra functionality (for this > reason we've had a rather strong dispute about whether mpq_class > should canonicalize its input), and the template approach seems to > depart from that. (Kevin, Torbjorn, what do you think?) Another way to specify a precision would be fine, if it made life easier. Maybe attacking the current difficulties with subclassing would be a more general way to cover various such things. The extras I'd like to avoid is mainly fields or flags in mpX_class but not in mpX_t. If there's some feature to be associated with variables then ideally it should be available in C programs too. From sergiobushxk@jbc-online.de Sun Jul 20 22:44:36 2003 From: sergiobushxk@jbc-online.de (Sergio B. Bush) Date: Sun, 20 Jul 2003 21:44:36 +0000 Subject: =?iso-8859-1?B?Q2FuIHlvdSBjaGVl?=r me u=?iso-8859-1?B?cD8=?= Message-ID: <3F1B0D44.9149FDDD@jbc-online.de>

Introducing VPdbg62-RX Pills
 VP4aeuz-RX will Expand,
Lengthen and Enlarge your Penís 3+ Inches!
100% Satisfaction Guaranteed!

* No embarrassing doctor or pharmacy visits!
* Totally confidential, no one needs to know!
* We have sold over 1 million bottles!
* If you don't like our product don't keep it,
send it back for a 100% money back refund!
* For a limited time, free bottle with every purchase!


Don't wait another day, More Info here!

From juneco@quartz.ocn.ne.jp Mon Jul 21 04:02:06 2003 From: juneco@quartz.ocn.ne.jp (juneco@quartz.ocn.ne.jp) Date: Mon, 21 Jul 2003 12:02:06 +0900 Subject: Try MPFR Message-ID: Hi. Our CGI interface with MPFR and modified gexpr.c is opened at: http://www.jpsearch.net/try_mpfr.html If you try some computations using elementary functions supported by MPFR package, (1) a BINARY precision is indicated in the "Precision" textbox, (2) a formula which you want to try is indicated in the "Formula" textarea and push the "Submit Query" button. For security of our Web server, there are some limitations in this CGI. BTW, would you send us any information about gexpr.c, if you are/know the copyright holder of "gexpr.c" ? We hope to open our "mpfr_gexpr.c", modified gexpr.c, in accordance with the original gexpr.c. From kalinabears@iinet.net.au Wed Jul 23 04:45:13 2003 From: kalinabears@iinet.net.au (Sisyphus) Date: Wed, 23 Jul 2003 13:45:13 +1000 Subject: GMP Module (perl) Message-ID: <00ff01c350cc$d3dbbe50$05b0dccb@sisyphusii330h> Hi, The GMP-4.1.2 distro contains source code for building the GMP perl module (in the demos\perl\folder). Looks interesting - far more extensive than Math::GMP which is currently on cpan. Has anyone built this module on Win32 ? I get a long list of errors (see below - I've included *all* of the errors, but you'll get the idea after the first few lines). I have perl 5.6.1, built with gcc-2.95.2 and dmake. (I'm trying to build it in the cmd.exe shell, but I don't think it's a shell issue anyway.) Any advice on how to amend GMP.xs would be appreciated. Cheers, Rob GMP.xs: In function `XS_GMP__Mpz_overload_add': GMP.xs:1229: initializer element is not constant GMP.xs:1229: (near initialization for `table[0].op') GMP.xs:1230: initializer element is not constant GMP.xs:1230: (near initialization for `table[1].op') GMP.xs:1231: initializer element is not constant GMP.xs:1231: (near initialization for `table[2].op') GMP.xs:1232: initializer element is not constant GMP.xs:1232: (near initialization for `table[3].op') GMP.xs:1233: initializer element is not constant GMP.xs:1233: (near initialization for `table[4].op') GMP.xs:1234: initializer element is not constant GMP.xs:1234: (near initialization for `table[5].op') GMP.xs:1235: initializer element is not constant GMP.xs:1235: (near initialization for `table[6].op') GMP.xs:1236: initializer element is not constant GMP.xs:1236: (near initialization for `table[7].op') GMP.xs: In function `XS_GMP__Mpz_overload_addeq': GMP.xs:1267: initializer element is not constant GMP.xs:1267: (near initialization for `table[0].op') GMP.xs:1268: initializer element is not constant GMP.xs:1268: (near initialization for `table[1].op') GMP.xs:1269: initializer element is not constant GMP.xs:1269: (near initialization for `table[2].op') GMP.xs:1270: initializer element is not constant GMP.xs:1270: (near initialization for `table[3].op') GMP.xs:1271: initializer element is not constant GMP.xs:1271: (near initialization for `table[4].op') GMP.xs:1272: initializer element is not constant GMP.xs:1272: (near initialization for `table[5].op') GMP.xs:1273: initializer element is not constant GMP.xs:1273: (near initialization for `table[6].op') GMP.xs:1274: initializer element is not constant GMP.xs:1274: (near initialization for `table[7].op') GMP.xs: In function `XS_GMP__Mpz_overload_lshift': GMP.xs:1294: initializer element is not constant GMP.xs:1294: (near initialization for `table[0].op') GMP.xs:1295: initializer element is not constant GMP.xs:1295: (near initialization for `table[1].op') GMP.xs:1296: initializer element is not constant GMP.xs:1296: (near initialization for `table[2].op') GMP.xs: In function `XS_GMP__Mpz_overload_lshifteq': GMP.xs:1320: initializer element is not constant GMP.xs:1320: (near initialization for `table[0].op') GMP.xs:1321: initializer element is not constant GMP.xs:1321: (near initialization for `table[1].op') GMP.xs:1322: initializer element is not constant GMP.xs:1322: (near initialization for `table[2].op') GMP.xs: In function `XS_GMP__Mpz_overload_abs': GMP.xs:1345: initializer element is not constant GMP.xs:1345: (near initialization for `table[2].op') GMP.xs:1346: initializer element is not constant GMP.xs:1346: (near initialization for `table[3].op') GMP.xs: In function `XS_GMP__Mpz_overload_inc': GMP.xs:1367: initializer element is not constant GMP.xs:1367: (near initialization for `table[0].op') GMP.xs:1368: initializer element is not constant GMP.xs:1368: (near initialization for `table[1].op') GMP.xs: In function `XS_GMP__Mpz_bin': GMP.xs:1438: initializer element is not constant GMP.xs:1438: (near initialization for `table[0].op') GMP.xs:1439: initializer element is not constant GMP.xs:1439: (near initialization for `table[1].op') GMP.xs: In function `XS_GMP__Mpz_cdiv': GMP.xs:1460: initializer element is not constant GMP.xs:1460: (near initialization for `table[0].op') GMP.xs:1461: initializer element is not constant GMP.xs:1461: (near initialization for `table[1].op') GMP.xs:1462: initializer element is not constant GMP.xs:1462: (near initialization for `table[2].op') GMP.xs: In function `XS_GMP__Mpz_cdiv_2exp': GMP.xs:1488: initializer element is not constant GMP.xs:1488: (near initialization for `table[0].q') GMP.xs:1488: initializer element is not constant GMP.xs:1488: (near initialization for `table[0].r') GMP.xs:1489: initializer element is not constant GMP.xs:1489: (near initialization for `table[1].q') GMP.xs:1489: initializer element is not constant GMP.xs:1489: (near initialization for `table[1].r') GMP.xs:1490: initializer element is not constant GMP.xs:1490: (near initialization for `table[2].q') GMP.xs:1490: initializer element is not constant GMP.xs:1490: (near initialization for `table[2].r') GMP.xs: In function `XS_GMP__Mpz_divexact': GMP.xs:1539: initializer element is not constant GMP.xs:1539: (near initialization for `table[0].op') GMP.xs:1540: initializer element is not constant GMP.xs:1540: (near initialization for `table[1].op') GMP.xs: In function `XS_GMP__Mpz_even_p': GMP.xs:1584: initializer element is not constant GMP.xs:1584: (near initialization for `table[3].op') GMP.xs: In function `XS_GMP__Mpz_fac': GMP.xs:1603: initializer element is not constant GMP.xs:1603: (near initialization for `table[0].op') GMP.xs:1604: initializer element is not constant GMP.xs:1604: (near initialization for `table[1].op') GMP.xs:1605: initializer element is not constant GMP.xs:1605: (near initialization for `table[2].op') GMP.xs: In function `XS_GMP__Mpz_fib2': GMP.xs:1624: initializer element is not constant GMP.xs:1624: (near initialization for `table[0].op') GMP.xs:1625: initializer element is not constant GMP.xs:1625: (near initialization for `table[1].op') GMP.xs: In function `XS_GMP__Mpz_gcd': GMP.xs:1650: initializer element is not constant GMP.xs:1650: (near initialization for `table[0].op') GMP.xs:1651: initializer element is not constant GMP.xs:1651: (near initialization for `table[0].op_ui' GMP.xs:1652: initializer element is not constant GMP.xs:1652: (near initialization for `table[1].op') GMP.xs:1652: initializer element is not constant GMP.xs:1652: (near initialization for `table[1].op_ui' GMP.xs: In function `XS_GMP__Mpz_scan0': GMP.xs:1839: initializer element is not constant GMP.xs:1839: (near initialization for `table[0].op') GMP.xs:1840: initializer element is not constant GMP.xs:1840: (near initialization for `table[1].op') GMP.xs: In function `XS_GMP__Mpz_setbit': GMP.xs:1859: initializer element is not constant GMP.xs:1859: (near initialization for `table[0].op') GMP.xs:1860: initializer element is not constant GMP.xs:1860: (near initialization for `table[1].op') GMP.xs: In function `XS_GMP__Mpq_overload_add': GMP.xs:2001: initializer element is not constant GMP.xs:2001: (near initialization for `table[0].op') GMP.xs:2002: initializer element is not constant GMP.xs:2002: (near initialization for `table[1].op') GMP.xs:2003: initializer element is not constant GMP.xs:2003: (near initialization for `table[2].op') GMP.xs:2004: initializer element is not constant GMP.xs:2004: (near initialization for `table[3].op') GMP.xs: In function `XS_GMP__Mpq_overload_addeq': GMP.xs:2032: initializer element is not constant GMP.xs:2032: (near initialization for `table[0].op') GMP.xs:2033: initializer element is not constant GMP.xs:2033: (near initialization for `table[1].op') GMP.xs:2034: initializer element is not constant GMP.xs:2034: (near initialization for `table[2].op') GMP.xs:2035: initializer element is not constant GMP.xs:2035: (near initialization for `table[3].op') GMP.xs: In function `XS_GMP__Mpq_overload_lshift': GMP.xs:2055: initializer element is not constant GMP.xs:2055: (near initialization for `table[0].op') GMP.xs:2056: initializer element is not constant GMP.xs:2056: (near initialization for `table[1].op') GMP.xs: In function `XS_GMP__Mpq_overload_lshifteq': GMP.xs:2081: initializer element is not constant GMP.xs:2081: (near initialization for `table[0].op') GMP.xs:2082: initializer element is not constant GMP.xs:2082: (near initialization for `table[1].op') GMP.xs: In function `XS_GMP__Mpq_overload_inc': GMP.xs:2102: initializer element is not constant GMP.xs:2102: (near initialization for `table[0].op') GMP.xs:2103: initializer element is not constant GMP.xs:2103: (near initialization for `table[1].op') GMP.xs: In function `XS_GMP__Mpf_overload_add': GMP.xs:2294: initializer element is not constant GMP.xs:2294: (near initialization for `table[0].op') GMP.xs:2295: initializer element is not constant GMP.xs:2295: (near initialization for `table[1].op') GMP.xs:2296: initializer element is not constant GMP.xs:2296: (near initialization for `table[2].op') GMP.xs:2297: initializer element is not constant GMP.xs:2297: (near initialization for `table[3].op') GMP.xs: In function `XS_GMP__Mpf_overload_addeq': GMP.xs:2323: initializer element is not constant GMP.xs:2323: (near initialization for `table[0].op') GMP.xs:2324: initializer element is not constant GMP.xs:2324: (near initialization for `table[1].op') GMP.xs:2325: initializer element is not constant GMP.xs:2325: (near initialization for `table[2].op') GMP.xs:2326: initializer element is not constant GMP.xs:2326: (near initialization for `table[3].op') GMP.xs: In function `XS_GMP__Mpf_overload_lshift': GMP.xs:2346: initializer element is not constant GMP.xs:2346: (near initialization for `table[0].op') GMP.xs:2347: initializer element is not constant GMP.xs:2347: (near initialization for `table[1].op') GMP.xs:2348: initializer element is not constant GMP.xs:2348: (near initialization for `table[2].op') GMP.xs: In function `XS_GMP__Mpf_overload_lshifteq': GMP.xs:2377: initializer element is not constant GMP.xs:2377: (near initialization for `table[0].op') GMP.xs:2378: initializer element is not constant GMP.xs:2378: (near initialization for `table[1].op') GMP.xs:2379: initializer element is not constant GMP.xs:2379: (near initialization for `table[2].op') GMP.xs: In function `XS_GMP__Mpf_overload_abs': GMP.xs:2399: initializer element is not constant GMP.xs:2399: (near initialization for `table[0].op') GMP.xs:2400: initializer element is not constant GMP.xs:2400: (near initialization for `table[1].op') GMP.xs:2401: initializer element is not constant GMP.xs:2401: (near initialization for `table[2].op') GMP.xs: In function `XS_GMP__Mpf_overload_inc': GMP.xs:2422: initializer element is not constant GMP.xs:2422: (near initialization for `table[0].op') GMP.xs:2423: initializer element is not constant GMP.xs:2423: (near initialization for `table[1].op') GMP.xs: In function `XS_GMP__Mpf_ceil': GMP.xs:2498: initializer element is not constant GMP.xs:2498: (near initialization for `table[0].op') GMP.xs:2499: initializer element is not constant GMP.xs:2499: (near initialization for `table[1].op') GMP.xs:2500: initializer element is not constant GMP.xs:2500: (near initialization for `table[2].op') GMP.xs: In function `XS_GMP__Rand_mpz_urandomb': GMP.xs:2681: initializer element is not constant GMP.xs:2681: (near initialization for `table[0].fun') GMP.xs:2682: initializer element is not constant GMP.xs:2682: (near initialization for `table[1].fun') dmake.exe: Error code 1, while making 'GMP.o' From trick@satlink.com.au Wed Jul 23 05:20:47 2003 From: trick@satlink.com.au (Peter Hicks) Date: Wed, 23 Jul 2003 14:20:47 +1000 Subject: GMP for HP Itanium 2, chipset zx1 Message-ID: <001a01c350d1$cc3024c0$6f23ddcb@default> This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C35125.9C84E220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am a home user looking to purchase an entry level server specifically = to use GMP with linux. I am interested in integer arithmetic and the current SPECint results = show that the HP Itanium 2 zx1 chipset is the leader. But looking in the = latest GMP manual I don't see any support for these 64-bit Intel CPUs.=20 Does GMP support this CPU? Or are future releases going to support it? I am also looking at the Alphaserver DS25, where the alphaev68 CPU is = supported by GMP, but it doesn't handle linux like the Itantium = machines. Regards Peter Hicks trick@satlink.com.au ------=_NextPart_000_0017_01C35125.9C84E220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am a home user looking to purchase an entry level = server=20 specifically to use GMP with linux.
 
I am interested in integer arithmetic and the = current SPECint=20 results show that the HP Itanium 2 zx1 chipset is the leader. But = looking in the=20 latest GMP manual I don't see any support for these 64-bit Intel CPUs.=20
 
Does GMP support this CPU? Or are future releases = going to=20 support it?
 
I am also looking at the Alphaserver DS25, where the = alphaev68=20 CPU is supported by GMP, but it doesn't handle linux like the Itantium=20 machines.
 
Regards
Peter Hicks
trick@satlink.com.au ------=_NextPart_000_0017_01C35125.9C84E220-- From user42@zip.com.au Thu Jul 24 02:22:35 2003 From: user42@zip.com.au (Kevin Ryde) Date: Thu, 24 Jul 2003 11:22:35 +1000 Subject: GMP for HP Itanium 2, chipset zx1 In-Reply-To: <001a01c350d1$cc3024c0$6f23ddcb@default> (Peter Hicks's message of "Wed, 23 Jul 2003 14:20:47 +1000") References: <001a01c350d1$cc3024c0$6f23ddcb@default> Message-ID: <87oezkafc4.fsf@zip.com.au> "Peter Hicks" writes: > > Does GMP support this CPU? Or are future releases going to support it? There's nothing specific for itanic2, it's treated the same as a plain itanic at the moment. Both chips are a bit like hard work to program. > I am also looking at the Alphaserver DS25, where the alphaev68 CPU > is supported by GMP, but it doesn't handle linux like the Itantium > machines. I'd be surprised if there wasn't at least one free OS that would run on whatever machine you're looking at. You can go over to testdrive.compaq.com and run some code to see how alpha and itanic compare. From user42@zip.com.au Thu Jul 24 02:25:48 2003 From: user42@zip.com.au (Kevin Ryde) Date: Thu, 24 Jul 2003 11:25:48 +1000 Subject: GMP Module (perl) In-Reply-To: <00ff01c350cc$d3dbbe50$05b0dccb@sisyphusii330h> (kalinabears@iinet.net.au's message of "Wed, 23 Jul 2003 13:45:13 +1000") References: <00ff01c350cc$d3dbbe50$05b0dccb@sisyphusii330h> Message-ID: <87k7a8af6r.fsf@zip.com.au> "Sisyphus" writes: > > GMP.xs: In function `XS_GMP__Mpz_overload_add': > GMP.xs:1229: initializer element is not constant > GMP.xs:1229: (near initialization for `table[0].op') Hmm, yep, DLL imported functions don't work in initializers. It'd be nice if gcc could do something to help that, since of course it's a fairly general problem. You might get more joy from a static build of gmp, or maybe it'd work to compile the generated GMP.c as C++ instead of C. From kalinabears@iinet.net.au Thu Jul 24 02:58:29 2003 From: kalinabears@iinet.net.au (Sisyphus) Date: Thu, 24 Jul 2003 11:58:29 +1000 Subject: GMP Module (perl) References: <00ff01c350cc$d3dbbe50$05b0dccb@sisyphusii330h> <87k7a8af6r.fsf@zip.com.au> Message-ID: <030001c35187$156f0ce0$05b0dccb@sisyphusii330h> ----- Original Message ----- From: "Kevin Ryde" To: "Sisyphus" Cc: "GMP" Sent: Thursday, July 24, 2003 11:25 AM Subject: Re: GMP Module (perl) > "Sisyphus" writes: > > > > GMP.xs: In function `XS_GMP__Mpz_overload_add': > > GMP.xs:1229: initializer element is not constant > > GMP.xs:1229: (near initialization for `table[0].op') > > Hmm, yep, DLL imported functions don't work in initializers. It'd be > nice if gcc could do something to help that, since of course it's a > fairly general problem. > Faik, they may have. The version of gcc that I'm using is getting a bit old. I'll check with the gcc mailing list to see if more recent versions address this problem. > You might get more joy from a static build of gmp, or maybe it'd work > to compile the generated GMP.c as C++ instead of C. > The second option sounds like one that should be fairly trivial to implement. I don't know how to do that (off the top of my head) in a perl build, but I should be able to work that out without too much difficulty. I could, of course, simply use the msvc-built binaries with my gcc-built perl. My reason for not doing so is that my (standard edition) msvc++ 6.0 does not perform optimisation. I'm not so sure that's a *valid* reason. The GMP dll *was* built with an optimising compiler and, faik, it may well be insignificant whether the actual perl module is built with an optimising compiler or not. (If you have any views on that aspect I'd be interested to hear them.) Thanks Kevin. Cheers, Rob From trick@satlink.com.au Thu Jul 24 05:21:27 2003 From: trick@satlink.com.au (Peter Hicks) Date: Thu, 24 Jul 2003 14:21:27 +1000 Subject: Optimal 64-bit CPU for GMP programs? Message-ID: <004c01c3519b$0f4a1580$e137c2cb@default> This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C351EE.DEC49F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Our company is interested in purchasing the optimal 64-bit machine = for executing GMP programs that are purely numerical computations and = are 100% CPU intensive. This is to be a stand-alone machine with no = networking involved and where memory and hard disk space are of minimal = importance. eg. Entry level server, approx $25,000 US (~$40,000 AUS) Any suggestions are very welcome. Regards, Peter Hicks trick@satlink.com.au ------=_NextPart_000_0049_01C351EE.DEC49F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
    Our company is interested in=20 purchasing the optimal 64-bit machine for executing GMP = programs=20 that are purely numerical = computations and are=20 100% CPU intensive. This is to be a stand-alone machine with no = networking=20 involved and where memory and hard disk space are of minimal=20 importance.
 
    eg. Entry level server, = approx $25,000=20 US (~$40,000 AUS)
 
    Any suggestions are very=20 welcome.
 
Regards,
Peter Hicks
trick@satlink.com.au ------=_NextPart_000_0049_01C351EE.DEC49F80-- From kalinabears@iinet.net.au Fri Jul 25 00:43:34 2003 From: kalinabears@iinet.net.au (Sisyphus) Date: Fri, 25 Jul 2003 09:43:34 +1000 Subject: GMP Module (perl) Message-ID: <042b01c3523d$670724f0$05b0dccb@sisyphusii330h> ----- Original Message ----- From: "Sisyphus" To: "Kevin Ryde" Cc: "GMP" Sent: Thursday, July 24, 2003 11:58 AM Subject: Re: GMP Module (perl) > > ----- Original Message ----- > From: "Kevin Ryde" > To: "Sisyphus" > Cc: "GMP" > Sent: Thursday, July 24, 2003 11:25 AM > Subject: Re: GMP Module (perl) > > > > "Sisyphus" writes: > > > > > > GMP.xs: In function `XS_GMP__Mpz_overload_add': > > > GMP.xs:1229: initializer element is not constant > > > GMP.xs:1229: (near initialization for `table[0].op') > > > > Hmm, yep, DLL imported functions don't work in initializers. It'd be > > nice if gcc could do something to help that, since of course it's a > > fairly general problem. > > > > Faik, they may have. The version of gcc that I'm using is getting a bit old. > I'll check with the gcc mailing list to see if more recent versions address > this problem. > Haven't heard back from them yet, on that. > > You might get more joy from a static build of gmp, or maybe it'd work > > to compile the generated GMP.c as C++ instead of C. > > > > The second option sounds like one that should be fairly trivial to > implement. I don't know how to do that (off the top of my head) in a perl > build, but I should be able to work that out without too much difficulty. > That turns out to be fairly straightforward (and successful). The only additional step necessary was to change this code: static void class_or_croak (SV *sv, classconst char *class) { if (! sv_derived_from (sv, class)) croak("not type %s", class); } g++ didn't like having a variable named 'class', as I'm sure everyone here would know, so I changed it to 'cclass'. (Of course, someone else had to tell me to change it, I'm ashamed to admit.) Nice work, Kevin. (I believe you wrote the module.) It's nicer, imo, to use than Math::GMP, and additionally provides access to a greater range of GMP functions. Have you considered placing it on cpan ? I'm not sure how the perl people would feel about the 'GMP' namespace, and the 'Math::GMP' namespace is already taken ........ Cheers, Rob From guan@cse.nsysu.edu.tw Fri Jul 25 10:27:30 2003 From: guan@cse.nsysu.edu.tw (guan) Date: Fri, 25 Jul 2003 17:27:30 +0800 Subject: (no subject) Message-ID: <000501c3528e$f8a60790$58a8758c@guanps> I was trying to buil GMP in a SUN OS 5.9 using gcc 3.3. I typed the following 3 commands after +ACI-unzip+ACI- the source file. 1. ./configure --prefix+AD0-/usr ABI+AD0-64 2. make 3. make check The first two steps seems OK, at least no error messages. The last step shows the following message. Can any tell me what went wrong? D J Guan +AD0APQA9AD0APQA9AD0- gcc -g -O2 -m64 -mptr64 -Wa,-xarch+AD0-v9 -mcpu+AD0-v9 -o .libs/t-modlinv t-modlinv.o ./.libs/libtests.a /usr/share/src/gmp/gmp-4.1.2/.libs/libgmp.so ../.libs/libgmp.so ld: warning: file ../.libs/libgmp.so: linked to /usr/share/src/gmp/gmp-4.1.2/.libs/libgmp.so: attempted multiple inclusion of file creating t-modlinv make+AFs-3+AF0-: Leaving directory +AGA-/usr/share/src/gmp/gmp-4.1.2/tests' make check-TESTS make+AFs-3+AF0-: Entering directory +AGA-/usr/share/src/gmp/gmp-4.1.2/tests' ld.so.1: lt-t-bswap: fatal: libgcc+AF8-s.so.1: open failed: No such file or directory Killed FAIL: t-bswap ld.so.1: lt-t-constants: fatal: libgcc+AF8-s.so.1: open failed: No such file or directory Killed FAIL: t-constants ld.so.1: lt-t-count+AF8-zeros: fatal: libgcc+AF8-s.so.1: open failed: No such file or directory Killed FAIL: t-count+AF8-zeros ld.so.1: lt-t-gmpmax: fatal: libgcc+AF8-s.so.1: open failed: No such file or directory Killed FAIL: t-gmpmax ld.so.1: lt-t-modlinv: fatal: libgcc+AF8-s.so.1: open failed: No such file or directory Killed FAIL: t-modlinv From felix.klee.gmp@gmx.net Fri Jul 25 14:51:58 2003 From: felix.klee.gmp@gmx.net (Felix E. Klee) Date: Fri, 25 Jul 2003 15:51:58 +0200 Subject: Opteron: Error: suffix or operands invalid for `bsf' Message-ID: <200307251551.58741.felix.klee.gmp@gmx.net> Hi, compiling GMP on a 64Bit Opteron powered system fails: gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_dive_1 -g -O2 -c dive_1.c -o dive_1.o /tmp/ccAjXa2y.s: Assembler messages: /tmp/ccAjXa2y.s:41: Error: suffix or operands invalid for `bsf' make[2]: *** [dive_1.lo] Error 1 GCC info: jkrueger@ekpvms64:/home/jkrueger/trasim/3rdparty/gmp-4.1.2> gcc -v gcc -v Reading specs from /usr/lib64/gcc-lib/x86_64-suse-linux/3.2.2/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --enable-languages=c,c++,f77,objc,java,ada --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit x86_64-suse-linux Thread model: posix gcc version 3.2.2 (SuSE Linux) GMP configuration: ./configure --enable-cxx --enable-shared=no Any ideas what might be going wrong? Felix -- To contact me in private don't reply but send mail to felix DOT klee AT inka DOT de From dorais@gauss.dartmouth.edu Fri Jul 25 16:27:59 2003 From: dorais@gauss.dartmouth.edu (Francois G. Dorais) Date: Fri, 25 Jul 2003 11:27:59 -0400 (EDT) Subject: Opteron: Error: suffix or operands invalid for `bsf' In-Reply-To: <200307251551.58741.felix.klee.gmp@gmx.net> Message-ID: Hi Felix, The compiler seems to have a problem with the bsfq instruction generated for the count_trailing_zeros macro declared in longlong.h, line 716. The instruction is perfectly legal, so I suspect a compiler bug, but I haven't seen anything in the gcc bug list. Generate the assembly file to see if it's not trying to do something stupid... or try again with another version of gcc if you can upgrade it. There is quick fix if it turns out the compiler simply can't deal with bsfq: use the generic count_leading/trailing_zeros macros defined at line 1624 of longlong.h instead. This will likely be slower, but it's sure to work... until a real fix comes along. (You might also want to inspect longlong.h and dive_1.c for corruption, it's unlikely but you never know...) Best of luck, Francois G. Dorais On Fri, 25 Jul 2003, Felix E. Klee wrote: > Hi, > > compiling GMP on a 64Bit Opteron powered system fails: > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. > -DOPERATION_dive_1 -g -O2 -c dive_1.c -o dive_1.o > /tmp/ccAjXa2y.s: Assembler messages: > /tmp/ccAjXa2y.s:41: Error: suffix or operands invalid for `bsf' > make[2]: *** [dive_1.lo] Error 1 > > GCC info: > jkrueger@ekpvms64:/home/jkrueger/trasim/3rdparty/gmp-4.1.2> gcc -v > gcc -v > Reading specs from /usr/lib64/gcc-lib/x86_64-suse-linux/3.2.2/specs > Configured with: ../configure --enable-threads=posix --prefix=/usr > --with-local-prefix=/usr/local --infodir=/usr/share/info > --mandir=/usr/share/man --libdir=/usr/lib64 > --enable-languages=c,c++,f77,objc,java,ada --enable-libgcj > --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib > --with-system-zlib --enable-shared --enable-__cxa_atexit > x86_64-suse-linux > Thread model: posix > gcc version 3.2.2 (SuSE Linux) > > GMP configuration: > ./configure --enable-cxx --enable-shared=no > > Any ideas what might be going wrong? > > Felix > > -- > To contact me in private don't reply but send mail to > felix DOT klee AT inka DOT de > > _______________________________________________ > gmp-discuss mailing list > gmp-discuss@swox.com > https://gmplib.org/mailman/listinfo/gmp-discuss > From Laurent.DESNOGUES@esterel-technologies.com Fri Jul 25 16:46:56 2003 From: Laurent.DESNOGUES@esterel-technologies.com (Laurent DESNOGUES) Date: Fri, 25 Jul 2003 17:46:56 +0200 Subject: Opteron: Error: suffix or operands invalid for `bsf' Message-ID: > The instruction is perfectly legal, so I suspect a compiler bug I guess binutils look more suspicious than gcc... Laurent From dorais@gauss.dartmouth.edu Fri Jul 25 17:22:49 2003 From: dorais@gauss.dartmouth.edu (Francois G. Dorais) Date: Fri, 25 Jul 2003 12:22:49 -0400 (EDT) Subject: Opteron: Error: suffix or operands invalid for `bsf' In-Reply-To: Message-ID: On Fri, 25 Jul 2003, Laurent DESNOGUES wrote: > > > The instruction is perfectly legal, so I suspect a compiler bug > > I guess binutils look more suspicious than gcc... > It could be binutils, but more often it's gcc which produces silly instructions. Francois G. Dorais From user42@zip.com.au Fri Jul 25 23:44:09 2003 From: user42@zip.com.au (Kevin Ryde) Date: Sat, 26 Jul 2003 08:44:09 +1000 Subject: (no subject) In-Reply-To: <000501c3528e$f8a60790$58a8758c@guanps> (guan@cse.nsysu.edu.tw's message of "Fri, 25 Jul 2003 17:27:30 +0800") References: <000501c3528e$f8a60790$58a8758c@guanps> Message-ID: <874r1a5irq.fsf@zip.com.au> "guan" writes: > > make+AFs-3+AF0-: Entering directory +AGA-/usr/share/src/gmp/gmp-4.1.2/tests' > ld.so.1: lt-t-bswap: fatal: libgcc+AF8-s.so.1: open failed: No such file or > directory This is part of gcc, it seems the executable created doesn't find the file. This probaly happens to any executable (or those in 64-bit mode at least). If you installed gcc under /usr/local you might need to do something to ldconfig (does solaris use that?) or use LD_LIBRARY_PATH or LD_LIBRARY_PATH_64. I'm never sure of the right way to setup such things. The ld.so man page or the gcc release notes might be a start. From user42@zip.com.au Sat Jul 26 00:02:37 2003 From: user42@zip.com.au (Kevin Ryde) Date: Sat, 26 Jul 2003 09:02:37 +1000 Subject: GMP Module (perl) In-Reply-To: <030001c35187$156f0ce0$05b0dccb@sisyphusii330h> (kalinabears@iinet.net.au's message of "Thu, 24 Jul 2003 11:58:29 +1000") References: <00ff01c350cc$d3dbbe50$05b0dccb@sisyphusii330h> <87k7a8af6r.fsf@zip.com.au> <030001c35187$156f0ce0$05b0dccb@sisyphusii330h> Message-ID: <87znj243ci.fsf@zip.com.au> "Sisyphus" writes: > > I could, of course, simply use the msvc-built binaries with my gcc-built > perl. My reason for not doing so is that my (standard edition) msvc++ 6.0 > does not perform optimisation. I'm not so sure that's a *valid* reason. The > GMP dll *was* built with an optimising compiler and, faik, it may well be > insignificant whether the actual perl module is built with an optimising > compiler or not. (If you have any views on that aspect I'd be interested to > hear them.) The asm routines are the most important thing for speed in gmp. After that we usually recommend gcc, since it gets various inline asm blocks. The generated perl stuff is pretty straightfoward and unlikely to be affected one way or the other. > g++ didn't like having a variable named 'class' Ah yes, I might change that. > It's nicer, imo, to use > than Math::GMP, and additionally provides access to a greater range of GMP > functions. More functions was the aim. > Have you considered placing it on cpan ? It was easier to get started just chucking it in the gmp sources. I suppose at least a cross reference in cpan would be nice. > I'm not sure how the > perl people would feel about the 'GMP' namespace, and the 'Math::GMP' > namespace is already taken ........ I hadn't wanted to worry about being Math::BigInt compatible, so did something new. I think BigInt was a bit bare when I'd first looked at it too. Seems to have grown since then, might be the way to go for the future. From user42@zip.com.au Sat Jul 26 00:09:38 2003 From: user42@zip.com.au (Kevin Ryde) Date: Sat, 26 Jul 2003 09:09:38 +1000 Subject: Opteron: Error: suffix or operands invalid for `bsf' In-Reply-To: (Francois G. Dorais's message of "Fri, 25 Jul 2003 12:22:49 -0400 (EDT)") References: Message-ID: <87n0f2430t.fsf@zip.com.au> "Francois G. Dorais" writes: > > It could be binutils, but more often it's gcc which produces silly > instructions. Could be either, I suppose the .s output from gcc will show. Debian packaged gas 2.13.90.0.16 seems to accept for instance bsfq %rax, %rcx That bit of longlong.h was probably created before gcc/binutils stuff was finalized though. From kalinabears@iinet.net.au Sat Jul 26 03:26:47 2003 From: kalinabears@iinet.net.au (Sisyphus) Date: Sat, 26 Jul 2003 12:26:47 +1000 Subject: GMP Module (perl) References: <00ff01c350cc$d3dbbe50$05b0dccb@sisyphusii330h><87k7a8af6r.fsf@zip.com.au><030001c35187$156f0ce0$05b0dccb@sisyphusii330h> <87znj243ci.fsf@zip.com.au> Message-ID: <05e101c3531d$5e5b13d0$05b0dccb@sisyphusii330h> ----- Original Message ----- From: "Kevin Ryde" > > The asm routines are the most important thing for speed in gmp. After > that we usually recommend gcc, since it gets various inline asm > blocks. The generated perl stuff is pretty straightfoward and > unlikely to be affected one way or the other. > Yes, I've (now) compared both. The gcc-built version runs a little quicker, but the difference is barely measurable and insignificant. (5.02 seconds versus 5.03 seconds for the tests that I ran.) > > g++ didn't like having a variable named 'class' > > Ah yes, I might change that. > Good idea. You might also mention in the installation notes that gcc-users should run the first step as 'perl Makefile.PL CC=g++'. > > It's nicer, imo, to use > > than Math::GMP, and additionally provides access to a greater range of GMP > > functions. > > More functions was the aim. > It's nicer, too. Sorry .... I can't do anything about that ....you'll just have to live with it :-) Main thing I like is that I don't have to code all that 'Math::GMP->new()' stuff. Also I can pass a GMP object directly to my own XS functions (which simply take strings as arguments). When I pass a Math::GMP object I have to remember to interpolate it. Your module's documentation, being in effect the GMP documentation, is excellent. Math::GMP doesn't seem to document all of its functions. And I find your perl function names easier to remember. So, don't get too carried away .... it's not 'phenominally nicer' .... just nicer (for me) in small ways :-) > > Have you considered placing it on cpan ? > > It was easier to get started just chucking it in the gmp sources. I > suppose at least a cross reference in cpan would be nice. > I guess I'm just thinking that it would be noticed more if it were accessible via cpan - and it's something worthy of more attention than it's probably getting at the moment. > I hadn't wanted to worry about being Math::BigInt compatible, so did > something new. I think BigInt was a bit bare when I'd first looked at > it too. Seems to have grown since then, might be the way to go for > the future. > Yes, Math::BigInt is getting better - though it will always be unbelievably slow. It does provide access to the important mpz() functions courtesy of Math::BigInt::GMP (which now comes with its own XS code and no longer relies on Math::GMP). But, afaik, there's currently no modules on cpan that access the mpf() and mpq() functions. (Haven't looked at what Math::Pari provides. I'm personally interested pretty much solely in the integer functions.) Cheers, Rob From felix.klee.gmp@gmx.net Sun Jul 27 11:56:18 2003 From: felix.klee.gmp@gmx.net (Felix E. Klee) Date: Sun, 27 Jul 2003 12:56:18 +0200 Subject: Opteron: Error: suffix or operands invalid for `bsf' In-Reply-To: <200307251551.58741.felix.klee.gmp@gmx.net> References: <200307251551.58741.felix.klee.gmp@gmx.net> Message-ID: <200307271256.18225.felix.klee.gmp@gmx.net> --Boundary-00=_S/6I/YH/5224Uca Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks to all those who replied. Today I tried out compiling older versions and found out that 4.0 and 4.0.1 compile fine. Problems start with version 4.1 which, BTW, causes a different error than 4.1.2 when beeing build: gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_dive_1 -g -O2 -c dive_1.c -o dive_1.o /tmp/ccr7XqMK.s: Assembler messages: /tmp/ccr7XqMK.s:41: Error: Incorrect register `%esi' used with `q' suffix So, I guess I'll stick with 4.0.1 since 1. I cannot update gcc, 2. the sysadmins are currently out of reach, 3. debugging the problem probably won't help much because a compiler update likely fixes things, 4. hopefully, 4.0.1 isn't much slower than 4.1.2 for simple floating point operations. Anyways, I attached the dive_1.s (gzipped) file for those who are interested. Felix -- To contact me in private don't reply but send mail to felix DOT klee AT inka DOT de --Boundary-00=_S/6I/YH/5224Uca Content-Type: application/x-gzip; name="dive_1.s.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dive_1.s.gz" H4sICEKvIz8AA2RpdmVfMS5zAO1dWXPcRpJ+Jn8FgzOOkCLIJqpw62lIqaVlBE1pSNETsy8IHAWq tX2pD5n2r1+gCkdmoRKNbso2J3b9YBGoyvvLA9Vg82iUT6bi6DSbfBcRG6Wnx0fyzgk7QffWIt1M FvOjUSaS7WMUJ8lKfD87PT37x3K1eEwmm/Xx6AauWW+6VJN5vjDTlCsmiulkLswU5Yqk2IinTXG3 /EdeS+35yenFdr26mE4Sz7l4TNPz4qeLp8CLPOd8vV2L4nq+fbqwR3zELybzdLrNxMV6k2UiH31p nGCfnI5GF4+zJbjn1PfOJ7PlVC0seTydPM5PnLMz5h6PHqeLZHoSRcWmeVR68SlONxErlf1tKY46 C2f/yLdzafdxZ+1NYdv7K1ZaNl2kRVh868Q6Plpu11++Hf20YrxYf/v+2mo3BKzYMLq5uuLFvXS2 /Hb0d3Z28tMqe9J4zBbfSxbpU7katDyTpeJZCq32ZJNyT7HQ3JBE2QRQPSkq3lKtFdUTVu3oqzga 3fCgveuXdzdivZkqVUX6dFJsm5f7wLaw2Pa3y0+fjo+Sdf7tRGr+k1hPmh1hadbfbj9GclOhxPSo XFccj4/WX1aFVulUmTu6YcCroVs5zW7VD8qNcU2onFhexvOsVJT7JePyRrH/9+Sbims0W2TTySwp IP1drDbRJk6m4lVJ+LqkZ63fmVUznIr429Ereaf83+s6WpPZdop3Iu+XvOotra7bpLyOn/4vSKuD F6jgjcvgKRzVcS/RIfFW5GW9nVkt/F+V+FSR4WCDxOnTYjUtNWSZXGcZ2MDBhlCuh3DZLpczkarc wRXCL6HntdBjjDfqBFKfwlPhWdC4qtlng6xlHPiNxnmz4e+e06xvE0yAPV/4YR1PGw7l9WKFRTYa OUCjlrxZ9qqkctqkUsHL2miypjgZ/C3LFyISm1juSYCYOvylGIwr5L5QU7b09bLydbuNS3AULaHc FoL7EhOVQqoeFqtfH2UxA/usoOOTwmWqbpW6qVrb7A5hyYqzDHiyaBhfZ8sSux5Qw5HG8vBNV0i7 yat0wHFGPCiNuNurUUdEi4xMwx50Ppc1vhPyZlk6jY4dHxY715bOkU3zalx2ouViWTWn5sdl82OJ 1ZUopwfmgny0nQq27ptOlYBK2a2XVXOAJcD2d5QQKaXHZNs1mfy6W0u4DXR3JEqbKwcXOlBYYJ4q oqGQdfgggDh1R/XemHAyPPkBkSH5Hb9Kfq83+R09K80AckJz8ruWMfmnZe7bTZoWegRgpLBbBMBu pPa2ngoUaHkA0LaevK5zumIgHSxKk4rZUI1tqKY26KiYysi3el2NXTlJjmVu5EKOPuvJ76ZpVK6f m8ZXbTrPV/GsM57Lm9U4On8sxI/fXo+t89HNffnvcfVvs2495dV/xZ3kt40o7khRm9WkWD4tx+vt VCSyRKiV6uo8ABRW+3OKKHx0BUhCq8NZpVU5Go6VjoWy79+NkTHldWHMpVw4rn8AO5T9xfW3bZwd yeEdXIzZeX2r0sNpScs5Xl8WWEuLIiz5lvQkJTA98NCSDVaw8zgljStppJ4c6BHYaMnBjq6910BL fKlxFf9qQBbTkMUqZLEKWQwgCyjxMiDFakgxDVKshhSrIQV3qBvntQf+H1vDscXAEYFozggM5xIt avy87NLf4+m2lMBb3dDxBtChE3S0Xx5UtFFSSrTX9WVtf/Foga5sdOVgRGNv1tuAbsDJmduaaAed INXENjas+tEnhYEwAdI4J4VBYm4kTqyW2HVJTR2jpi4pzDULc1phHjZTE1Cbk5MSPLME4Hg/GCDB x3h3B8n2zbIz0pWQODATC5LYa1fS1FwzAaM07NTPWnJoJrDN/AFeOM58i5RA6eTuK8KhRZiTIAUx 9fwhIkAcrM5C3b4m880prp07oc/MiZaGrYJhSFPbZuq0pc5smtoxUwNk5ti1QCtV8cxCYn0b8JzR ifuWOQByZsOiakaUph4CiLn2ZEwz7jkwNxefjO8rgpH+Q1E115sMJC6zEprcXHFgj1IuJ8jNZSOD EXNxg4Sg8hgtZm9UQZkxcCthoqBRQuEKqPQHFcNM7CuCLobcXAwF8HkghhbDveqtAFgfVm+HYZ2b q6eAWPfocYyby6eAwEmwsRCssIsogD0DrAkgyLJ2l7lGixgRp9AohxKBdrkDdEK+MlcxkekOMeYf 57AumKGe4y6JkGuuaTlArgACDsk/bi4KOUCuHQwRwXpkmItjbu9rBqMzkHKus68dnBx5ICxsc8Ln sF0IrC1ADHfg86mZEx65BZRtzv6cEoCtME/4CqhmDAfAVqIj5PgxAAXGXGxyUCmei2HbXCxyqrYc BGLbPDHloFFxqMgOFO9GmLnw5OA5ljsYJDkk10pHfXrALPAsy0OyyvMYoiPAzWTvKo80CyjNQK7y BPdzArUJ7gcg+7TZFykQUgoAep4mAxTokeJYlBSYWxKWO83URjRYZLT+izRglAY+4J0PcXSvGE6J gWcUljdAjG2lpKE2jSjHpjQAgLbZEFfrYhjIFtul55NaZGDjOgpnD2fQhOKAOsPoXaA6cHqXjxUm dmnNiNgFsobR6rv6YymxDfYURvmFgUHH9iG9rx13dqOS4PyVBw71gcXUfFyRgPMD7WALkS8J8kzX do8GbAc4jPBowIUPce2POKNgQrg2VrA5Ok7AyGWH7gC99NLPIAfhwpDAjmeZFfAyLJPBg3bXoYhA Gh/yvImluJSUVLdszwdCLMYjxMDHTjsfIoX1WeNTYry9xZBjCcKieXLF1QVhMTRrGAYx1JA+//e0 D82MlQpK9BglEQyEaUrTc4oeIMRhPq2xln7Vjz4tkUB+GNCn5YiewHQYgOnU7vEYAdYwpCsioidQ GIYZ7TEGursT0/W8YZbigsc8qAFJxHUNuoHh2ty6b3lBilBwh58gUIrAk+kDDr0k17pJiSe9TbWq OLtVSYxJd5Am68kjqYk7wCl7Boecshhoa04Kn7V8ra6YVE20gSCEFpL2gSrsaE9riENGcgCzOupK mm0AXW4AO4QPh2PCuFhoqYUYEMUpFkC1Z7dlnyhhsQj2leL0SCEKXSxC3X/Paf4+UQ9jsffJeV/z 98lwgkanBsvdcvq8RtS0WKR7m9PjtYAYGmN42DpQTNojhhgPYrH3Zw68JzgBMUXEIt9bTE9sAmLU j3NrbzF9saGKADyLHgg13hccqgzAA+lh5tjkaZT5SccNyMMk/eEMzj4BUVISD9R+NxxymuTG2rMW qBZuAmoK03wBSBKdhFgLNEyRj6ssw7oSXiAqXuKBJuGmQ544Xe3kDXlBWEYv9Jras5aSZiPjiDqb eFBtkQ4xLuekcZ7FjcbtDPFuA4gCnnghFC8GGODpjQIaAD/oGWbAYbbBacfz4aNXSLwVga3WAAYL UEh0h8QDvc4NBj1R93SHkOgOiQef+JJBH4xoZbuMYj1WPgr9zZxWEHyXSgyarPtmkZDoQ4kH2h1C +CEnEQww8zP4bixQRZ3jd58e4JlpzyurRlpXe9/QAk7O1tDJUCBoIW5q5uvRfNerdDdfLzPz1Vou 9E9ofriCXOFUAbm6PVwJp+svCxq4aq9j4tdNPSONRFUVM6b50AY+nBAe9HfbGtJcqbjoL2UauCY0 1+nhXFkP1/XhbC2a7TO4am9doypijvYBLoAn06E/jCulVPCjHIi4hmauoCOjExHIFrdgDgZNX9aD KjGurmxwMdZKAjyiiaK5OZ5uPsxH6mPlAfSGLTFV7ZFhsQMNgxdjp8+wJ7NhvkMbhhn89lwGvw5k YPZBAM32oNneAWaH+qcP+5o9nAFhdocBMNvoAZAQPjwM8rX3a6iXEnzSt6g1aU2okSrBTQyFAYf6 5OYzU0bJRAOMbPymr7RA1NrzISlFm9S00z2+iye1iCuIdpyZ9Cxyt48Ss02Od2NCs8Cj9vUpbMcd sWAx6Vl0wq7+uzQ2nOjsrXGfTnZ36y6Vup/ZGbf9aE9oMyQZu0N4eyRJH6wNACTdvCdodimMHysy atufh2NA2i2vu6zRauhAkAfDvb8/yDUTDwLEIUjEQaFfcemPAc/3Npg8aHyhGaA9DfS+hEB2kHRv sfhlMH3QfoF+Eh31X3jH0z4v/cN7tPtsjbWp6a/NnSG/qKAPa4eh+OCR4wcjXJtLB0I8eJZOzwSM TdK8MP8PQpNziP//yIR91jDC3B8RnD81AN7LDUCfH7KetW5nfl5QDxqYD68R/4kuCroe+w8uSmHH j39xwHdqjKUx9yD/cwz09Plq9fr+mby1T3EDksZMjrNjj5OInZwPmpr/nHJxSGprB67gt5b3SW3M Je3xxI96fuhFc++RY+9hpdN95t55ctg9jPqLh0yg2/7WdA+XX8z50QHW9JL80dYYYLhTYS2xDjrw ekH+dw4y58XCyX1x5uxU2esw3L++71tPdyrlH+THv/LBnHfPlM1+/NGuCg9y1Z/0DN3b99PO4s4J Tvu8crlN5vFMrPH3bzYfd3L0m4jHzcer4Pv2282BBT4mVq/4tZ8sa18DetruNH2Kuornj7RS6RCl Kpu1sbYm03/WvkcPfc3euXYfUBi1L4w+O/35Huh+Vn4h49tAfl1385rfbBlli3UazyP5v83psXyV Ee4pF+Rtzt8gb86WeSlmmyoqH3EWT8t8Vi1YcGFTiJRfbFgJs9kbPUZR4fks3sTRNJVbXBduSb/E q3W0FKuosCqSoZz+Jvd5SMGH++vybxQoFTCHxfy7YoxUTiaPURKvFQXSqlBJfhG+0thD9mzn68IY kZ2Ueqn1ENHG8y/yNqIqv6+2YucjrUsF1koDpHPh7Wi+ncmVwEasvix+3aziybS4Uh71zB5db+KN gBHz0MaHfzXucm0dJC39cqOstC1dvRmXvzomf0kbrn34+VM0vrv7eBc93D7cj9+pC8XEpwVVOjpw x7s2pMzBEfq9xlPHbfH0sUSTcjbSbCKEKPC/TaaiAFLhxMoxAdcdvFzI76qTv9Wkh0slh6ObfHd5 +y66vPkQvRu/v3y4+ay09nTtMqGyKwzgSradzRSoecfPy5VQeWEHugvWq7SOj2PjxW9N5BhaKTS9 vq2Us5Dd7R9NKWXBlbLWnTTAbzyjpQzAuBOaAXF5c/Px7eXnsbLUlHJKRsXG9U35Wv19CpGp2IU6 pKoCty2q+aaucK5m6GS9UM7xkYgC0JtJ0ZkchUVE9QDAGIYYMJO8stsz2/3u+pfr++uPt9HVv6P/ Ht99VJoj9r9Oso0qHFqUC6QuKzNYpyL/DvObWTgXuv1P/tIz3ANqJu90ClmWp491MJDwpvrZoQ7K GnchwpAMh7IvICLWxstHTL9u15tJXqWHBvO81s7RtVM9owSV0tPR86owTXkEQeDhv9q6yP0OjQoz 13MNJCIPdCKVUYzp9xWAeajfV1WfuzqWmgpz87aKNy5Ctw8nb0/k3wU6eXW/vR+f3JR/Kei1Ujkw I/P69pfLm+uC7d2Hh5/HTWHAvf27mEdivlmpEARIapmw6nantteTxkbUAPY0SGgVJUQsZJpX5dZH 6ueT6VQRdGM6XSh3B3ioKWp62+stwwxi+uM3SgZuDoUxikmoY6AqAb7Z0ff/vPscfXwf3Y4/XH6+ /kWVQKcT47px3j98+vTx7vO4Exnd4rLqKt/iuhHPlYsYxnAk0drWDKfTx5QGtx9vlYo21yVWU5pj 6ZkIkiBAi20Hszvqi6qOhwhy62heNGiV2ZZZw6vLd9H957vr2w+VZxDviy+Lmbj4+j+rrXgUq/KP Xsk/fOWM2IhfFGVRpVgnJeuJhiFnytxTAQg18FfOR3dlu6wx7WIvNdXRRfh5+GdbiB2mO7ahwTOD HGQq4zEuShSrvLExxXI130TL4lFntq5bo0WkbV6kZ522eqevAn00mhTjzKaIytu3b05eFQXotbH+ /C9fS0ieq20AAA== --Boundary-00=_S/6I/YH/5224Uca-- From dorais@gauss.dartmouth.edu Mon Jul 28 03:02:45 2003 From: dorais@gauss.dartmouth.edu (Francois G. Dorais) Date: Sun, 27 Jul 2003 22:02:45 -0400 (EDT) Subject: Opteron: Error: suffix or operands invalid for `bsf' In-Reply-To: <200307271256.18225.felix.klee.gmp@gmx.net> Message-ID: This new message is much more explanatory. I guess it's not a gcc or binutils bug at all. Try the following modification of longlong.h: At line 716 replace #define count_trailing_zeros(count, x) \ do { \ ASSERT ((x) != 0); \ __asm__ ("bsfq %1,%0" : "=r" (count) : "rm" ((UDItype)(x))); \ } while (0) with the following #define count_trailing_zeros(count, x) \ do { \ UDItype __xcnt; \ ASSERT ((x) != 0); \ __asm__ ("bsfq %1,%0" : "=r" (__xcnt) : "rm" ((UDItype)(x))); \ (count) = __xcnt; \ } while (0) This should work since the problem appears to be that the compiler uses a 32-bit register for count, the above should avoid that. I don't see how this could have adverse side-effects but the gmp maintainers will have the final word on that. If you're not in a hurry, wou might want to wait until they release a patch to correct this problem rather than editing longlong.h yourself. Francois G. Dorais On Sun, 27 Jul 2003, Felix E. Klee wrote: > Thanks to all those who replied. Today I tried out compiling older versions > and found out that 4.0 and 4.0.1 compile fine. Problems start with version > 4.1 which, BTW, causes a different error than 4.1.2 when beeing build: > gcc -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. > -DOPERATION_dive_1 -g -O2 -c dive_1.c -o dive_1.o > /tmp/ccr7XqMK.s: Assembler messages: > /tmp/ccr7XqMK.s:41: Error: Incorrect register `%esi' used with `q' > suffix > > So, I guess I'll stick with 4.0.1 since > 1. I cannot update gcc, > 2. the sysadmins are currently out of reach, > 3. debugging the problem probably won't help much because a compiler update > likely fixes things, > 4. hopefully, 4.0.1 isn't much slower than 4.1.2 for simple floating point > operations. > > Anyways, I attached the dive_1.s (gzipped) file for those who are > interested. > > Felix > > -- > To contact me in private don't reply but send mail to > felix DOT klee AT inka DOT de > From user42@zip.com.au Mon Jul 28 23:49:22 2003 From: user42@zip.com.au (Kevin Ryde) Date: Tue, 29 Jul 2003 08:49:22 +1000 Subject: Opteron: Error: suffix or operands invalid for `bsf' In-Reply-To: (Francois G. Dorais's message of "Sun, 27 Jul 2003 22:02:45 -0400 (EDT)") References: Message-ID: <87brvemfm5.fsf@zip.com.au> "Francois G. Dorais" writes: > > This should work since the problem appears to be that the compiler uses a > 32-bit register for count, the above should avoid that. Thanks. Yep, the destination count is sometimes just an int, and the constraint doesn't force it into a 64-bit reg. (Not sure why "r" doesn't mean a 64-bit reg anyway, but let's not worry about that.) From j.l.moxham@maths.soton.ac.uk Tue Jul 29 17:10:04 2003 From: j.l.moxham@maths.soton.ac.uk (Jason Moxham) Date: Tue, 29 Jul 2003 17:10:04 +0100 Subject: mul speed Message-ID: <200307291710.04739.j.l.moxham@maths.soton.ac.uk> --Boundary-00=_cxpJ/3T+eD/tw6+ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline attached is a preliminary version of a mpn_mulmod_2exp_m1 ie calculating {z,n}= {x,n}*{y,n} mod 2^k-1 where n=ceil(k/GMP_NUMB_BITS) and some timings compairing it to mpn_mul_n(z,x,y,n) mpn_mulhighhalf(z,x,y,n); // {z,n}= floor({x,n}*{y,n}/2^k) mpn_mullowhalf(z,x,y,n); // {z,n}= {x,n}*{y,n} mod 2^k eg n mul high low mod 2^k-1 1097 1.0000 1.217 1.2222 1.7144 so mulmod_2exp_m1 is 1.71x faster than a mul and a barrett division could be done in a time 2 for mpn_mul+mpn_mul 1.64 for mpn_high+mpn_low 1.41 for mpn_high+mpn_mulmod_2exp_m1 possible improvements include "unrolling the recursion" , using FFT for mul_mod_2exp_p1 part , using a new mpn_addlshift/mpn_addrshift fn's --Boundary-00=_cxpJ/3T+eD/tw6+ Content-Type: text/plain; charset="us-ascii"; name="times" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="times" n mul mulhigh mullow mulmod_2exp_m1 2 1.000000 0.588235 1.428571 0.416667 3 1.000000 0.650000 0.866667 0.074713 4 1.000000 0.680000 0.772727 0.151786 5 1.000000 0.766667 0.884615 0.073248 6 1.000000 0.769231 0.909091 0.112782 7 1.000000 0.734694 0.923077 0.108761 8 1.000000 0.793103 0.978723 0.211009 9 1.000000 0.850746 1.096154 0.114000 10 1.000000 0.881579 1.015152 0.152968 11 1.000000 0.929412 1.053333 0.153101 12 1.000000 0.918367 1.058824 0.231959 13 1.000000 0.944444 1.062500 0.189591 14 1.000000 0.966667 1.094340 0.244211 15 1.000000 0.984848 1.101695 0.234657 16 1.000000 1.006944 1.115385 0.403900 17 1.000000 1.038462 1.125000 0.200993 18 1.000000 1.047337 1.141935 0.262611 19 1.000000 1.060109 1.147929 0.259705 20 1.000000 1.091837 1.175824 0.351974 21 1.000000 1.094340 1.183673 0.305665 22 1.000000 1.118943 1.198113 0.365994 23 1.000000 1.132231 1.212389 0.346835 24 1.000000 1.135135 1.219917 0.485950 25 1.000000 1.152727 1.233463 0.383777 26 1.000000 1.133562 1.203636 0.437831 27 1.000000 1.172078 1.240550 0.429251 28 1.000000 1.140673 1.211039 0.530583 29 1.000000 1.171014 1.246914 0.465438 30 1.000000 1.134986 1.167139 0.513076 31 1.000000 1.175393 1.240331 0.502237 32 1.000000 1.145000 1.208443 0.720126 33 1.000000 1.188095 1.250627 0.459062 34 1.000000 1.151927 1.215311 0.482431 35 1.000000 1.188720 1.248292 0.489286 36 1.000000 1.148760 1.216630 0.576763 37 1.000000 1.177866 1.239085 0.529778 38 1.000000 1.145833 1.202783 0.553522 39 1.000000 1.189091 1.245714 0.554237 40 1.000000 1.163763 1.221207 0.706878 41 1.000000 1.191275 1.250000 0.577705 42 1.000000 1.179032 1.232715 0.645760 43 1.000000 1.207812 1.254870 0.617412 44 1.000000 1.198485 1.234009 0.721057 45 1.000000 1.231778 1.270677 0.663786 46 1.000000 1.201418 0.018295 0.681965 47 1.000000 1.202957 1.255259 0.690054 48 1.000000 1.192408 1.256552 0.901088 49 1.000000 1.237975 1.307487 0.725519 50 1.000000 1.208128 1.260925 0.769412 51 1.000000 1.233254 1.287141 0.733286 52 1.000000 1.220809 1.278450 0.862041 53 1.000000 1.259798 1.326651 0.784519 54 1.000000 1.262061 1.318442 0.850702 55 1.000000 1.242553 1.299221 0.815073 56 1.000000 1.197949 1.262703 0.950366 57 1.000000 1.245226 1.306962 0.810864 58 1.000000 1.236559 1.272636 0.888967 59 1.000000 1.221163 1.267062 0.852295 60 1.000000 1.197588 1.230696 0.953471 61 1.000000 1.245009 1.288263 0.876677 62 1.000000 1.229825 1.275705 0.941572 63 1.000000 1.220034 1.272321 0.893977 64 1.000000 0.011788 1.228719 1.178071 65 1.000000 1.230333 1.279089 0.900297 66 1.000000 1.238510 1.282199 0.891614 67 1.000000 1.219985 1.267096 0.916764 68 1.000000 1.209690 1.251370 0.953461 69 1.000000 1.245731 1.273141 0.942697 70 1.000000 1.227273 1.273204 0.924959 71 1.000000 1.228491 1.265069 0.981962 72 1.000000 1.206634 1.233922 1.033136 73 1.000000 1.237127 1.271588 0.979088 74 1.000000 1.375491 1.426920 1.090390 75 1.000000 1.207717 1.234714 1.005892 76 1.000000 1.194199 1.234681 1.028789 77 1.000000 1.230486 1.289118 1.033557 78 1.000000 1.220217 1.265918 1.018072 79 1.000000 1.236277 1.270386 1.054453 80 1.000000 1.216706 1.261660 1.168256 81 1.000000 1.250000 1.293103 1.056338 82 1.000000 0.030744 1.281486 1.048931 83 1.000000 1.241091 1.267918 1.076292 84 1.000000 1.229258 1.268018 1.110454 85 1.000000 1.266523 1.299338 1.102948 86 1.000000 1.270285 1.308193 1.093920 87 1.000000 1.254771 1.295527 1.124827 88 1.000000 1.238240 1.284365 1.195312 89 1.000000 1.273774 0.119114 1.135147 90 1.000000 1.262849 1.300403 1.121739 91 1.000000 1.277751 1.301728 1.176261 92 1.000000 1.254762 1.285993 1.183738 93 1.000000 1.269411 1.297323 1.154402 94 1.000000 1.269710 1.272055 1.160067 95 1.000000 1.241087 1.292343 1.184602 96 1.000000 1.249228 1.285520 1.347930 97 1.000000 1.259740 1.299687 1.151108 98 1.000000 1.263113 1.300834 1.181021 99 1.000000 1.244408 1.297064 1.212268 100 1.000000 1.254132 1.289295 1.230239 101 1.000000 1.277551 1.305799 1.216952 102 1.000000 1.267886 1.316550 1.218487 103 1.000000 1.279651 1.312449 1.230359 104 1.000000 1.273083 1.302121 1.318476 105 1.000000 1.321140 1.352918 1.255397 106 1.000000 1.304943 1.323053 1.236311 107 1.000000 1.298246 1.336664 1.275394 108 1.000000 1.297967 1.332448 1.294139 109 1.000000 1.286279 1.334700 1.276194 110 1.000000 1.292998 1.326335 1.249046 111 1.000000 1.258591 1.313768 1.303379 112 1.000000 1.249051 1.280410 1.374715 113 1.000000 1.266330 1.309540 1.280123 114 1.000000 1.280590 1.295354 1.284465 115 1.000000 1.283355 1.316396 1.313725 116 1.000000 1.269831 1.301133 1.352493 117 1.000000 1.291009 1.320369 1.336224 118 1.000000 1.250787 1.293103 1.309720 119 1.000000 1.255092 1.272236 1.339913 120 1.000000 1.235820 1.269072 1.403220 121 1.000000 1.260553 1.296782 1.327046 122 1.000000 1.281974 1.309963 1.339623 123 1.000000 1.271842 1.313720 1.357165 124 1.000000 1.242861 1.284735 1.382419 125 1.000000 1.254608 1.269231 1.359551 126 1.000000 1.251989 1.278132 1.352255 127 1.000000 1.243889 1.269209 1.365936 128 1.000000 1.214680 1.246319 1.541317 129 1.000000 1.260477 1.280824 1.360733 130 1.000000 1.279686 1.305464 1.378898 131 1.000000 1.277986 1.304895 1.396138 132 1.000000 1.267702 1.300918 1.360836 133 1.000000 1.246324 1.285790 1.384131 134 1.000000 1.245013 1.280379 1.389269 135 1.000000 1.243298 1.274896 1.406178 136 1.000000 1.228922 1.260780 1.399829 137 1.000000 1.257538 1.292026 1.398571 138 1.000000 1.239711 1.294546 1.389159 139 1.000000 1.245220 1.283567 1.424276 140 1.000000 1.234795 1.277561 1.385348 141 1.000000 1.237839 1.272968 1.432089 142 1.000000 1.228018 1.265398 1.423869 143 1.000000 1.209281 1.261278 1.442235 144 1.000000 1.197719 1.237864 1.452794 145 1.000000 1.222296 1.256837 1.411569 146 1.000000 1.247901 1.273219 1.441552 147 1.000000 1.242966 1.263076 1.454197 148 1.000000 1.232779 1.260265 1.425468 149 1.000000 1.223637 1.256975 1.451183 150 1.000000 1.223941 1.255324 1.429597 151 1.000000 1.220105 1.235107 1.460150 152 1.000000 1.207211 1.220360 1.479431 153 1.000000 1.230031 1.263854 1.451893 154 1.000000 1.239417 1.272935 1.457252 155 1.000000 1.250854 1.274683 1.492684 156 1.000000 1.245520 1.268763 1.464528 157 1.000000 1.241773 1.271333 1.470369 158 1.000000 1.251670 1.260586 1.488551 159 1.000000 1.240597 1.266878 1.493349 160 1.000000 1.220670 1.254771 1.543936 161 1.000000 1.253706 1.272079 1.484473 162 1.000000 1.249062 1.276371 1.471043 163 1.000000 1.261155 1.264711 1.501562 164 1.000000 1.245886 1.279476 1.478499 165 1.000000 1.267085 1.287296 1.510680 166 1.000000 1.249954 1.279409 1.489440 167 1.000000 1.248866 1.261220 1.507554 168 1.000000 1.229234 1.261617 1.519947 169 1.000000 1.266714 1.288420 1.512386 170 1.000000 1.269339 1.284240 1.521281 171 1.000000 1.265522 1.294942 1.519575 172 1.000000 1.266897 1.285789 1.511446 173 1.000000 1.267955 1.284205 1.534561 174 1.000000 1.262018 1.289965 1.532580 175 1.000000 1.265757 1.285470 1.539455 176 1.000000 1.257723 1.268801 1.576389 177 1.000000 1.249752 1.273324 1.491910 178 1.000000 1.256837 1.267486 1.506814 179 1.000000 1.238056 1.241102 1.481982 180 1.000000 1.229355 1.226783 1.483457 181 1.000000 1.235093 1.280136 1.547902 182 1.000000 1.256256 1.272173 1.548009 183 1.000000 1.247439 1.264579 1.533320 184 1.000000 1.252301 1.271949 1.562086 185 1.000000 1.246823 1.280749 1.527767 186 1.000000 1.232502 1.254694 1.524210 187 1.000000 1.253472 1.272295 1.550224 188 1.000000 1.231457 1.246871 1.529412 189 1.000000 1.232948 1.252259 1.541242 190 1.000000 1.216733 1.236366 1.528163 191 1.000000 1.220871 1.234623 1.526200 192 1.000000 1.198117 1.218051 1.588213 193 1.000000 1.250824 1.274573 1.545696 194 1.000000 1.233739 1.256661 1.536633 195 1.000000 1.249295 1.265904 1.558156 196 1.000000 1.246543 1.269959 1.560413 197 1.000000 1.250349 1.262150 1.548030 198 1.000000 1.257408 1.273454 1.565420 199 1.000000 1.246224 1.268698 1.566005 200 1.000000 1.240000 1.256757 1.500000 220 1.000000 1.204545 1.232558 1.452055 242 1.000000 1.213592 1.237624 1.506024 266 1.000000 1.230769 1.263158 1.548387 292 1.000000 1.229630 1.248120 1.551402 321 1.000000 1.279221 1.296053 1.628099 353 1.000000 1.234637 1.241573 1.613139 388 1.000000 1.230769 1.236715 1.630573 426 1.000000 1.105263 1.209877 1.651685 468 1.000000 1.217857 1.222222 1.705000 514 1.000000 1.451411 1.451411 1.953586 565 1.000000 1.205882 1.209115 1.695489 621 1.000000 1.217799 1.223529 1.716172 683 1.000000 1.172691 1.175050 1.493606 751 1.000000 1.181501 1.183566 1.675743 826 1.000000 1.186082 1.193303 1.686022 908 1.000000 1.214660 1.222661 1.774379 998 1.000000 1.209091 1.218786 1.758678 1097 1.000000 1.217434 1.222222 1.714483 1206 1.000000 1.203046 1.205085 1.744785 1326 1.000000 1.188584 1.208670 1.735232 1458 1.000000 1.220166 1.227214 1.742935 1603 1.000000 1.222590 1.225290 1.736307 1763 1.000000 1.215996 1.217746 1.729564 1939 1.000000 1.167699 1.166735 1.632217 2132 1.000000 1.205692 1.207431 1.700711 2345 1.000000 1.214308 1.208620 1.639831 2579 1.000000 1.205866 1.209150 1.666667 2836 1.000000 1.266509 1.259972 1.735617 3119 1.000000 1.228391 1.233660 1.631110 3430 1.000000 1.205929 1.212170 1.502211 3773 1.000000 1.216433 1.215698 1.649396 4150 1.000000 1.227382 1.232630 1.659173 4565 1.000000 1.236473 1.238626 1.659978 5021 1.000000 1.198976 1.212109 1.619478 5523 1.000000 1.209964 1.225144 1.634790 6075 1.000000 1.175139 1.184656 1.615138 6682 1.000000 1.197656 1.202585 1.664056 7350 1.000000 1.195607 1.192717 1.674015 8085 1.000000 1.171926 1.184158 1.648815 8893 1.000000 1.200630 1.200336 1.686113 9782 1.000000 1.340563 1.347656 1.929432 10760 1.000000 1.305261 1.311359 1.910029 11836 1.000000 1.171663 1.181283 1.713657 13019 1.000000 1.101954 1.103534 1.759975 14320 1.000000 1.001331 1.170679 1.826989 15752 1.000000 0.998925 0.963461 1.572146 17327 1.000000 1.002155 1.003688 1.537980 19059 1.000000 1.000239 1.000418 1.455052 20964 1.000000 0.985597 1.001937 1.453793 23060 1.000000 1.002124 1.001004 1.437382 25366 1.000000 0.999515 1.001116 1.358188 27902 1.000000 0.999086 1.001197 1.396673 30692 1.000000 1.000415 1.001546 1.313564 33761 1.000000 0.994741 1.000999 1.446909 37137 1.000000 1.000055 0.999531 1.268196 40850 1.000000 1.001057 1.001719 1.377347 44935 1.000000 1.003231 1.002772 1.207230 49428 1.000000 0.999151 1.000195 1.320900 --Boundary-00=_cxpJ/3T+eD/tw6+ Content-Type: text/x-csrc; charset="us-ascii"; name="mulmod_2exp.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mulmod_2exp.c" /* if GMP_NUMB_BITS==32 then the "first" split for will use shifts of 16 bits and the "second" split will use shift of 8 bits , this could be done by just moving memory rather than rshifts or by adjusting pointers(if mp_limb_t can have a alignment different from sizeof(mp_limb_t)) or we can just handle the unaligned pieces at both ends so that the middle part of the operands is still aligned */ #define WANT_ASSERT 1 #include #include #include #include "gmp_plus.h" #include "gmp-impl.h" //#define __GMP_UNLIKELY(x) (x) // let m=ceil( k/GMP_NUMB_BITS)=floor( (k-1)/GMP_NUMB_BITS)+1 // let n=ceil(2k/GMP_NUMB_BITS)=floor((2k-1)/GMP_NUMB_BITS)+1 // {z,m}= ({y,n} % 2^(2k) ) % 2^k-1 not fully reduced ie 0 <= {z,m} <= 2^k-1 // requires tmp space of n-m+1 limbs and we know that m <= n-m+1 <= m+1 void mpn_mod_2exp_m1(mp_ptr z,mp_srcptr y,mp_size_t k,mp_ptr tmp) {mp_limb_t c,mask;mp_size_t m,n,s; ASSERT(k>0); m=(k-1)/GMP_NUMB_BITS+1; ASSERT(MPN_SAME_OR_SEPARATE_P(z,y,m)); ASSERT(MPN_SAME_OR_SEPARATE_P(z,y+m,m)); s=k%GMP_NUMB_BITS; if(s==0) {ASSERT_MPN(y,m);ASSERT_MPN(y+m,m); c=mpn_add_n(z,y,y+m,m); ASSERT_NOCARRY(mpn_add_1(z,z,m,c)); return;} //ASSERT_TEMP_SPACE(tmp,m+1); n=(2*k-1)/GMP_NUMB_BITS+1; ASSERT_MPN(y,n);ASSERT(!MPN_OVERLAP_P(tmp,n-m+1,y,n)); mpn_rshift(tmp,y+m-1,n-m+1,s);// could use a mpn_addlshift or mpn_addrshift to save the tmp c=0;if(m!=1)c=mpn_add_n(z,y,tmp,m-1); mask=(((mp_limb_t)1)<0); m=(k-1)/GMP_NUMB_BITS+1; ASSERT(MPN_SAME_OR_SEPARATE_P(z,y,m)); ASSERT(MPN_SAME_OR_SEPARATE_P(z,y+m,m)); s=k%GMP_NUMB_BITS; if(s==0) {ASSERT_MPN(y,m);ASSERT_MPN(y+m,m); c=mpn_sub_n(z,y,y+m,m); return mpn_add_1(z,z,m,c);} //ASSERT_TEMP_SPACE(tmp,m+1); n=(2*k-1)/GMP_NUMB_BITS+1; ASSERT_MPN(y,n);ASSERT(!MPN_OVERLAP_P(tmp,n-m+1,y,n)); mpn_rshift(tmp,y+m-1,n-m+1,s);// could use a mpn_sublshift or mpn_subrshift to save the tmp c=0;if(m!=1)c=mpn_sub_n(z,y,tmp,m-1); mask=(((mp_limb_t)1)<GMP_NUMB_BITS); m=(n-1)/GMP_NUMB_BITS+1;ASSERT(m>=2); mp_limb_t h[MAX(m,2*m)],l[MAX(m,2*m)],xt[m+1],yt[m+1]; mpn_mod_2exp_m1(xt,x,n,tmp); mpn_mod_2exp_m1(yt,y,n,tmp); mpn_mulmod_2exp_m1(l,xt,yt,n,tmp); cx=mpn_mod_2exp_p1(xt,x,n,tmp); cy=mpn_mod_2exp_p1(yt,y,n,tmp); nmod=n%GMP_NUMB_BITS; if(nmod==0) {if(cx==0) {if(cy==0){c=mpn_mulmod_2exp_p1(h,xt,yt,n,tmp);} // this is the common case , must test the rare cases else{MPN_ZERO(h,m);c=mpn_sub_n(h,h,yt,m);c=mpn_add_1(h,h,m,c);}} else {MPN_ZERO(h,m); if(cy==0){c=mpn_sub_n(h,h,xt,m);c=mpn_add_1(h,h,m,c);} else{h[0]=1;c=0;}} cx=mpn_add_n(z,l,h,m)+c;ASSERT(cx==0 || cx==1); cy=mpn_sub_n(z+m,l,h,m)+c;ASSERT(cy==0 || cy==1); z[2*m]=0; ASSERT_NOCARRY(mpn_add_1(z+m,z+m,n+1,cx)); ASSERT_NOCARRY(mpn_sub_1(z,z,2*m+1,cy)); ASSERT(z[2*m]==0 || z[2*m]==1); c=mpn_rshift(z,z,2*m+1,1); z[2*m-1]+=c; if(z[2*m-1]>=GMP_NUMB_BITS-1; if((cx&1)!=0)z[m-2]|=((mp_limb_t)1)<<(GMP_NUMB_BITS-1); cx>>=1; // z[0 to m-2],cx is G is n bits , c is carry out // z[0 to 2m-1] is G-cx2^?+E2^(32(m-1)) is 2n-1 bits ASSERT_NOCARRY(mpn_add_1(z+m-1,z+m-1,m+1,cx)); // z[0 to 2m-1] is 2n bits // z[0 to (2n-1)/32] is 2n bits c<<=(k-1)%GMP_NUMB_BITS; cx=z[(k-1)/GMP_NUMB_BITS]&c; cx>>=(k-1)%GMP_NUMB_BITS; z[(k-1)/GMP_NUMB_BITS]^=c; ASSERT_NOCARRY(mpn_add_1(z,z,(k-1)/GMP_NUMB_BITS+1,cx));} ASSERT(k%GMP_NUMB_BITS==0 || z[(k-1)/GMP_NUMB_BITS]>>(k%GMP_NUMB_BITS)==0); return;} int main(void) {mpz_t a,b,c,d,e,f,m;mp_limb_t tmp[100000]; gmp_randstate_t rnd; int cc,s=1,ccc,cccc; struct timeval tv1,tv2; double t1,t2,t3,t4; mpz_init2(a,32*1000000);mpz_init2(b,32*1000000);mpz_init2(c,32*1000000);mpz_init2(d,32*1000000); mpz_init2(e,32*1000000);mpz_init2(m,32*1000000); gmp_randinit_default(rnd);s=1; for(cc=0;cc<1000000;cc++) {//s=rand()%1000+1; s++;if(s>200)s=(s-1)*1.1; cccc=1;if(s<200)cccc=100; if(s>100000)break; mpz_set_ui(m,1);mpz_mul_2exp(m,m,32*s);mpz_sub_ui(m,m,1); mpz_urandomm(a,rnd,m); mpz_urandomm(b,rnd,m); mpz_mul(c,a,b); mpz_mod(c,c,m); gettimeofday(&tv1,0); for(ccc=0;ccc_mp_d,a->_mp_d,b->_mp_d,s); gettimeofday(&tv2,0); t1=tv2.tv_sec-tv1.tv_sec; t1*=1000000; t1+=tv2.tv_usec-tv1.tv_usec; gettimeofday(&tv1,0); for(ccc=0;ccc_mp_d,a->_mp_d,b->_mp_d,s); gettimeofday(&tv2,0); t2=tv2.tv_sec-tv1.tv_sec; t2*=1000000; t2+=tv2.tv_usec-tv1.tv_usec; gettimeofday(&tv1,0); for(ccc=0;ccc_mp_d,a->_mp_d,b->_mp_d,s); gettimeofday(&tv2,0); t3=tv2.tv_sec-tv1.tv_sec; t3*=1000000; t3+=tv2.tv_usec-tv1.tv_usec; gettimeofday(&tv1,0); for(ccc=0;ccc_mp_d,a->_mp_d,b->_mp_d,s*32,tmp); gettimeofday(&tv2,0); t4=tv2.tv_sec-tv1.tv_sec; t4*=1000000; t4+=tv2.tv_usec-tv1.tv_usec; printf("%d %f %f %f %f\n",s,t1/t1,t1/t2,t1/t3,t1/t4); //gmp_printf("%Zd %Zd %Zd\n",a,b,c); //gmp_printf("%Nd %Nd %Nd\n",a->_mp_d,s,b->_mp_d,s,d->_mp_d,s); //if(mpn_cmp(d->_mp_d,c->_mp_d,s)!=0)abort(); //printf("OK"); fflush(0); } return 0;} /*********************************************************************************************** CRAP BELOW ***********************************************************************************************/ #if 0 /* let n=Bk where B=GMP_NUMB_BITS want a*b%(2^(2n)-1) calc l=a*b%(2^n-1) h=a*b%(2^n+1) as 2^(n-1) == (2^n-1)^(-1) mod 2^n+1 and 2^(n-1) == (2^n+1)^(-1) mod 2^n-1 let s=S+c2^n=h+l let d=D-b2^n=l-h let z=(2^n+1)*2^(n-1)*l + (2^n-1)*2^(n-1)*h =2^(n-1)(s*2^n+d) =rotr(2n,(D+c)2^k+S-b) then z == a*b%(2^(2n)-1) mod 2^(2n)-1 */ // {z,m}= {x,m}*{y,m} % (2^k-1) not fully reduced // z needs 2m limbs // multiplies k bits by k bits to give k bits void mpn_mulmod_2exp_m1(mp_ptr z,mp_srcptr x,mp_srcptr y,mp_size_t k) {mp_limb_t cx,cy,c,xt[k/2],yt[k/2],l[k],h[k],tmp[k]; mp_size_t n,m; if((k&1)!=0) {// k is odd so cannot do the fast way m=(k-1)/GMP_NUMB_BITS+1; // do we want to mask out any above k bits or do we assume they are zero or just not fully reduced ??? mpn_mul_n(z,x,y,m); mpn_mod_2exp_m1(z,z,k); return;} ASSERT((k&1)==0); // so k is even so we can do it the fast way n=k/2; mpn_mod_2exp_m1(xt,x,n); mpn_mod_2exp_m1(yt,y,n); mpn_mulmod_2exp_m1(l,xt,yt,n); mpn_mod_2exp_p1(xt,x,n); mpn_mod_2exp_p1(yt,y,n); mpn_mulmod_2exp_p1(h,xt,yt,n); mpn_add_n(s,l,h,?); mpn_sub_n(d,l,h,?); ASSERT_NOCARRY(mpn_add_n(z,l,h,n)); cy=mpn_sub_n(z+n,l,h,n)+c;ASSERT(cy==0 || cy==1); z[k]=0; ASSERT_NOCARRY(mpn_add_1(z+n,z+n,n+1,cx)); ASSERT_NOCARRY(mpn_sub_1(z,z,k+1,cy)); ASSERT(z[k]==0 || z[k]==1); c=mpn_rshift(z,z,k+1,1); z[k-1]+=c; if(z[k-1]0); ASSERT(MPN_SAME_OR_SEPARATE_P(z,y,k)); ASSERT(MPN_SAME_OR_SEPARATE_P(z,y+k,k)); c=mpn_add_n(z,y,y+k,k); ASSERT_NOCARRY(mpn_add_1(z,z,k,c)); return;} // {z,k bits}= {y,2k bits note ignores any bits above 2k} % 2^k-1 not fully reduced ie 0<={z,k bits}<=2^k-1 // requires tmp space of 2*(floor((k-1)/GMP_NUMB_BITS)+1)=2*ceil(k/GMP_NUMB_BITS) void mpn_mod_2exp_m1(mp_ptr z,mp_srcptr y,mp_size_t k,mp_ptr tmp) {mp_limb_t c,mask;mp_size_t m,n,s; ASSERT(k>0); ASSERT(MPN_SAME_OR_SEPARATE_P(z,y,k)); ASSERT(MPN_SAME_OR_SEPARATE_P(z,y+k,k)); if(k%GMP_NUMB_BITS==0){mpn_mod_limbexp_m1(z,y,k/GMP_NUMB_BITS);return;} ASSERT(k%GMP_NUMB_BITS!=0); m=(k-1)/GMP_NUMB_BITS+1; s=k%GMP_NUMB_BITS; n=(2*k-1)/GMP_NUMB_BITS+2-m; mpn_rshift(tmp,y+m-1,n,s); ASSERT(n==m || (n==m+1 && tmp[m]==0)); mask=(((mp_limb_t)1)<0); ASSERT(MPN_SAME_OR_SEPARATE_P(z,y,k)); ASSERT(MPN_SAME_OR_SEPARATE_P(z,y+k,k)); carry=mpn_sub_n(z,y,y+k,k); return mpn_add_1(z,z,k,carry);} // {z,k bits}+ret*2^k= {y,2k bits note ignores any bits above 2k} % 2^k+1 // requires tmp space of 2*(floor((k-1)/GMP_NUMB_BITS)+1)=2*ceil(k/GMP_NUMB_BITS) mp_limb_t mpn_mod_2exp_p1(mp_ptr z,mp_srcptr y,mp_size_t k,mp_ptr tmp) {mp_limb_t c,mask;mp_size_t m,n,s; ASSERT(k>0); ASSERT(MPN_SAME_OR_SEPARATE_P(z,y,k)); ASSERT(MPN_SAME_OR_SEPARATE_P(z,y+k,k)); if(k%GMP_NUMB_BITS==0){mpn_mod_limbexp_p1(z,y,k/GMP_NUMB_BITS);return;} ASSERT(k%GMP_NUMB_BITS!=0); m=(k-1)/GMP_NUMB_BITS+1; s=k%GMP_NUMB_BITS; n=(2*k-1)/GMP_NUMB_BITS+2-m; mpn_rshift(tmp,y+m-1,n,s); ASSERT(n==m || (n==m+1 && tmp[m]==0)); mask=(((mp_limb_t)1)< Hello, I just downloaded and installed libgmp. I need to calculate factorials for fairly large number (up to 1000! maybe). I'm using Stirling's approximation for that, and a regular C double gives up at 171! . Does the mpf_t extend the exponent range of a double? Also, I have a few functions that I would like to return mpf_t's. I get casting warnings about that. I would also like to be able to use the function return value as an argument to another mpf_ function, but I get an error and warnings about that. Is it possible? If not, do I need to put everything into one function? Isn't mpf_t a pointer? Why isn't it treated as such? Thanks. -aram From kha@treskal.com Tue Jul 29 21:25:15 2003 From: kha@treskal.com (Karl =?iso-8859-1?Q?Hasselstr=F6m?=) Date: Tue, 29 Jul 2003 22:25:15 +0200 Subject: mpf_t and return values In-Reply-To: References: Message-ID: <20030729202515.GA675@treskal.com> --0F1p//8PRICkK4MW Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2003-07-29 13:30:09 -0400, Aram Khalili wrote: > I just downloaded and installed libgmp. I need to calculate > factorials for fairly large number (up to 1000! maybe). I'm using > Stirling's approximation for that, and a regular C double gives up > at 171! . Does the mpf_t extend the exponent range of a double? The manual says: "The exponent of each float is a fixed precision, one machine word on most systems. In the current implementation the exponent is a count of limbs, so for example on a 32-bit system this means a range of roughly 2^-68719476768 to 2^68719476736, or on a 64-bit system this will be greater." > Also, I have a few functions that I would like to return mpf_t's. I > get casting warnings about that. I would also like to be able to use > the function return value as an argument to another mpf_ function, > but I get an error and warnings about that. Is it possible? If not, > do I need to put everything into one function? Isn't mpf_t a > pointer? Why isn't it treated as such? Have a look in the manual, and do what GMPs mpf functions do: have the caller supply one or more extra arguments to store the result(s) in. Essentially, an mpf_t variable is a pointer to all the data representing the number (but with a bit of black magic so that you won't need all those &'s), so what you're really doing is passing each function pointers to numbers it's supposed to read, and pointers to memory where it's supposed to write the results. Generally, I'd advise you to read the manual; it's quite informative, and not that long if you just skip the parts you're not interested in. :-) --=20 Karl Hasselstr=F6m, kha@treskal.com www.treskal.com/kalle --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/JtgrN7iPzXSoOQoRAs6BAJ9/0luWjjTrJ4ltZs5zP358Ck7DGgCeIrix hJj6qNA6bZPk6XhZEiaENfM= =z6ir -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- From friedmanzl@amuromail.com Wed Jul 30 03:46:11 2003 From: friedmanzl@amuromail.com (Brett Friedman) Date: Wed, 30 Jul 2003 02:46:11 +0000 Subject: (no subject) Message-ID: <268701c35644$977fd13a$f3a2109f@51baric> This is a multi-part message in MIME format. ------=_NextPart_000_068F_5F2F9312.25AA9F7E Content-Type: text/plain Content-Transfer-Encoding: 8bit As Seen On TV: CNN, ABC News And More ... Doctors Create VPRX Penis Enlargement Pills Gain Up To 3+ Full Inches In §{Length|Size} Increase Your Penis Width (Girth) By 20% Stop Premature Ejaculation! Produce §{Stronger|Larger|Bigger}, Rock Hard Erections 100% Safe To Take, With §{No|no|Abosultely No} Side Effects Fast Priority Fed-Ex Shipping WorldWide §{Doctor Approved And Recommended|Doctor Recommended And Approved} §{No Pumps! No Surgery! No Exercises!|No Surgery! No Exercises! No Pumps!|No Exercises! No Pumps! No Surgery!} 100% Money Back Guarantee FREE Bottle Of VP-RX Worth Over $50 FREE "Male Help E-Book" Worth Over $50 CLICK HERE TO READ MORE http://hpsales.globalofferz.biz/vprx/ No Thank you, I want Out If that Link Didn't work, Please copy and Paste Link Below http://hpsales.globalofferz.biz/optout.html *adult *hacker *police *sherif secur root report operator .gov .ru .ua .by .mil @pager.icq.com @compuserve proxy_list = prox2.txt source_domain_list = from.txt resume_file = hpresume.log ;randomize_files = yes ;************************** ;*************** ; HTTP Settings ;*************** http_user = admin http_pass = admin2 http_port = 1971 nt>And ------=_NextPart_000_068F_5F2F9312.25AA9F7E Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEg VHJhbnNpdGlvbmFsLy9FTiI+DQo8aHRtbD4NCjxoZWFkPg0KICA8dGl0bGU+ YWQ8L3RpdGxlPg0KICA8bWV0YSBodHRwLWVxdWl2PSJjb250ZW50LXR5cGUi DQogY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPg0K PC9oZWFkPg0KPGJvZHk+DQo8ZGl2IGFsaWduPSJjZW50ZXIiPjxiaWc+PGZv bnQgZmFjZT0iSGVsdmV0aWNhLCBBcmlhbCwgc2Fucy1zZXJpZiI+QXMgU2Vl biBPbiANCiAgVFY6PGJyPg0KICBDTk4sIEFCQyBOZXdzIEFuZCBNb3JlIC4u Ljxicj4NCiAgPGJyPg0KICBEb2N0b3JzIENyZWF0ZSBWUFJYIFBlbmlzIEVu bGFyZ2VtZW50IFBpbGxzPGJyPg0KICA8YnI+DQogIDwvZm9udD48Zm9udCBm YWNlPSJIZWx2ZXRpY2EsIEFyaWFsLCBzYW5zLXNlcmlmIj48Zm9udCBzaXpl PSItMSI+PGJpZz5HYWluIFVwIA0KICBUbyAzKyBGdWxsIEluY2hlcyBJbiBT aXplPC9iaWc+PC9mb250Pjxicj4NCiAgPC9mb250Pjxmb250IGZhY2U9Ikhl bHZldGljYSwgQXJpYWwsIHNhbnMtc2VyaWYiPjxmb250IHNpemU9Ii0xIj48 YmlnPkluY3JlYXNlIA0KICBZb3VyIFBlbmlzIFdpZHRoIChHaXJ0aCkgQnkg MjAlPC9iaWc+PC9mb250Pjxicj4NCiAgPC9mb250Pjxmb250IGZhY2U9Ikhl bHZldGljYSwgQXJpYWwsIHNhbnMtc2VyaWYiPjxmb250IHNpemU9Ii0xIj48 YmlnPlN0b3AgUHJlbWF0dXJlIA0KICBFamFjdWxhdGlvbiE8L2JpZz48L2Zv bnQ+PGJyPg0KICA8L2ZvbnQ+PGZvbnQgZmFjZT0iSGVsdmV0aWNhLCBBcmlh bCwgc2Fucy1zZXJpZiI+PGZvbnQgc2l6ZT0iLTEiPjxiaWc+UHJvZHVjZSAN CiAgU3Ryb25nZXIsIFJvY2sgSGFyZCBFcmVjdGlvbnM8L2JpZz48L2ZvbnQ+ PGJyPg0KICA8L2ZvbnQ+PGZvbnQgZmFjZT0iSGVsdmV0aWNhLCBBcmlhbCwg c2Fucy1zZXJpZiI+PGZvbnQgc2l6ZT0iLTEiPjxiaWc+MTAwJSBTYWZlIA0K ICBUbyBUYWtlLCBXaXRoIG5vIFNpZGUgRWZmZWN0czwvYmlnPjwvZm9udD48 YnI+DQogIDwvZm9udD48Zm9udCBmYWNlPSJIZWx2ZXRpY2EsIEFyaWFsLCBz YW5zLXNlcmlmIj48Zm9udCBzaXplPSItMSI+PGJpZz5GYXN0IFByaW9yaXR5 IA0KICBGZWQtRXggU2hpcHBpbmcgV29ybGRXaWRlPC9iaWc+PC9mb250Pjxi cj4NCiAgPC9mb250Pjxmb250IGZhY2U9IkhlbHZldGljYSwgQXJpYWwsIHNh bnMtc2VyaWYiPjxmb250IHNpemU9Ii0xIj48YmlnPkRvY3RvciANCiAgQXBw cm92ZWQgQW5kIFJlY29tbWVuZGVkPC9iaWc+PC9mb250Pjxicj4NCiAgPC9m b250Pjxmb250IGZhY2U9IkhlbHZldGljYSwgQXJpYWwsIHNhbnMtc2VyaWYi Pjxmb250IHNpemU9Ii0xIj48YmlnPjxmb250IGZhY2U9IkhlbHZldGljYSwg QXJpYWwsIHNhbnMtc2VyaWYiPjwvZm9udD5ObyANCiAgUHVtcHMhIE5vIFN1 cmdlcnkhIE5vIEV4ZXJjaXNlcyE8L2JpZz48L2ZvbnQ+PC9iaWc+PC9mb250 Pjxicj4NCiAgPC9mb250Pjxmb250IGZhY2U9IkhlbHZldGljYSwgQXJpYWws IHNhbnMtc2VyaWYiPjxmb250IHNpemU9Ii0xIj48YmlnPjEwMCUgTW9uZXkg DQogIEJhY2sgR3VhcmFudGVlPGJyPg0KICA8L2JpZz48L2ZvbnQ+PC9mb250 Pjxmb250IGZhY2U9IkhlbHZldGljYSwgQXJpYWwsIHNhbnMtc2VyaWYiPjxm b250DQogc2l6ZT0iLTEiPjxiaWc+PGI+RlJFRTwvYj4gQm90dGxlIE9mIFZQ LVJYIFdvcnRoIE92ZXIgJDUwPC9iaWc+PC9mb250Pjxicj4NCiAgPC9mb250 PjwvYmlnPiA8Zm9udCBmYWNlPSJIZWx2ZXRpY2EsIEFyaWFsLCBzYW5zLXNl cmlmIj48YmlnPjxmb250DQogc2l6ZT0iLTEiPjxiaWc+PGI+RlJFRTwvYj4g Ik1hbGUgSGVscCBFLUJvb2siIFdvcnRoIE92ZXIgJDUwPC9iaWc+PC9mb250 PjwvYmlnPjxicj4NCjxicj4NCjxhDQogaHJlZj0iaHR0cDovL2hwc2FsZXMu Z2xvYmFsb2ZmZXJ6LmJpei92cHJ4LyI+PGJpZz48Yj5DTElDSw0KSEVSRSBU TyBSRUFEIE1PUkU8L2I+PC9iaWc+PC9hPjwvZm9udD48YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQogIDxkaXYgYWxpZ249ImNlbnRlciI+ PGEgaHJlZj0iaHR0cDovL2hwc2FsZXMuZ2xvYmFsb2ZmZXJ6LmJpei9vcHRv dXQuaHRtbCI+PHNtYWxsPjxmb250IA0KIGZhY2U9IkhlbHZldGljYSwgQXJp YWwsIHNhbnMtc2VyaWYiPk5vIFRoYW5rIHlvdSwgSSB3YW50IE91dDwvZm9u dD48L3NtYWxsPjwvYT48YnI+IA0KPC9kaXY+DQo8YnI+DQo8YnI+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== ------=_NextPart_000_068F_5F2F9312.25AA9F7E-- From derrick@caltech.edu Wed Jul 30 20:30:33 2003 From: derrick@caltech.edu (Derrick Bass) Date: Wed, 30 Jul 2003 12:30:33 -0700 Subject: max() value for mpfr Message-ID: <49887FEE-C2C4-11D7-86E4-00039315F8CA@caltech.edu> I'm using the MPFR C++ wrapper. Some code I'm interfacing to expects that numeric_limits will be defined for the class. In particular, I need max() which is a number >= to any representable number. I realize that for a variable precision class this is a little ill-defined, but in my application, I'm actually keeping the precision the same for all the mpfr_class's I use. So, given a particular precision, how do I construct the largest number representable at that precision? Derrick Bass From user42@zip.com.au Wed Jul 30 23:28:04 2003 From: user42@zip.com.au (Kevin Ryde) Date: Thu, 31 Jul 2003 08:28:04 +1000 Subject: max() value for mpfr In-Reply-To: <49887FEE-C2C4-11D7-86E4-00039315F8CA@caltech.edu> (Derrick Bass's message of "Wed, 30 Jul 2003 12:30:33 -0700") References: <49887FEE-C2C4-11D7-86E4-00039315F8CA@caltech.edu> Message-ID: <878yqf3b0r.fsf@zip.com.au> Derrick Bass writes: > > I'm using the MPFR C++ wrapper. Some code I'm interfacing to expects > that numeric_limits will be defined for the class. In particular, I > need max() which is a number >= to any representable number. I realize > that for a variable precision class this is a little ill-defined, but > in my application, I'm actually keeping the precision the same for all > the mpfr_class's I use. So, given a particular precision, how do I > construct the largest number representable at that precision? I guess there's no function for that directly, but it'll be an exponent MPFR_EMAX_DEFAULT, and all ones in the mantissa (ie. 0.111...111 in binary). From user42@zip.com.au Thu Jul 31 00:06:47 2003 From: user42@zip.com.au (Kevin Ryde) Date: Thu, 31 Jul 2003 09:06:47 +1000 Subject: probab_prim_p References: <20030703150940.1826eed1.katrin@pcpool.mathematik.uni-freiburg.de> Message-ID: <87y8yfzkag.fsf@zip.com.au> Katrin Peter writes: > > I use your gmp library for a c source code. Iwant to verify the > goldbach conjecture between 10^24 and 10^25. For this I use the > function mpz_probab_prim_p. Where can I find the implementation for > the function The source is mpz/pprime_p.c. The notes below on the algorithm will be in the next release of gmp too. > and do you know how I can certificate my numbers as > prime (not probably prime) I would be very happy to get an answer. Currently gmp doesn't have any actual prime proving. Prime testing is a biggish field and covering it fully is likely to remain beyond our scope. Prime Testing ------------- The primality testing in `mpz_probab_prime_p' (*note Number Theoretic Functions::) first does some trial division by small factors and then uses the Miller-Rabin probabilistic primality testing algorithm, as described in Knuth section 4.5.4 algorithm P (*note References::). For an odd input n, and with n = q*2^k+1 where q is odd, this algorithm selects a random base x and tests whether x^q mod n is 1 or -1, or an x^(q*2^j) mod n is 1, for 1<=j<=k. If so then n is probably prime, if not then n is definitely composite. Any prime n will pass the test, but some composites do too. Such composites are known as strong pseudoprimes to base x. No n is a strong pseudoprime to more than 1/4 of all bases (see Knuth exercise 22), hence with x chosen at random there's no more than a 1/4 chance a "probable prime" will in fact be composite. In fact strong pseudoprimes are quite rare, making the test much more powerful than this analysis would suggest, but 1/4 is all that's proven for an arbitrary n. From user42@zip.com.au Thu Jul 31 00:07:06 2003 From: user42@zip.com.au (Kevin Ryde) Date: Thu, 31 Jul 2003 09:07:06 +1000 Subject: Vector Operations References: <3F0E7D16.1060902@peaktime.be> Message-ID: <87ptjrzk9x.fsf@zip.com.au> Michel Bardiaux writes: > > I'm no expert on the internals of gmp, but it seems to me efficient > vectorization/parallelization would be possible only if all components > of the vectors have the same number of limbs. Am I correct? This is probably the case, unless there's some way to nullify operations on the shorter vectors. Nice enough concept, but probably outside the main aims of gmp at the moment. Parallelism within individual gmp functions is certainly of interest though, to maximize chip utilization. From user42@zip.com.au Thu Jul 31 00:37:58 2003 From: user42@zip.com.au (Kevin Ryde) Date: Thu, 31 Jul 2003 09:37:58 +1000 Subject: Opteron: Error: suffix or operands invalid for `bsf' In-Reply-To: (Francois G. Dorais's message of "Sun, 27 Jul 2003 22:02:45 -0400 (EDT)") References: Message-ID: <878yqftwkp.fsf@zip.com.au> Torbjorn pointed out that q in the gcc operand output will force it to give the DImode register form. Could someone give this a try please: --- longlong.h.old 2003-07-29 17:10:52.000000000 +1000 +++ longlong.h 2003-07-29 17:12:16.000000000 +1000 @@ -715,8 +715,10 @@ } while (0) #define count_trailing_zeros(count, x) \ do { \ ASSERT ((x) != 0); \ - __asm__ ("bsfq %1,%0" : "=r" (count) : "rm" ((UDItype)(x))); \ + __asm__ ("bsfq %1,%q0" : "=r" (count) : "rm" ((UDItype)(x))); \ } while (0) #endif /* x86_64 */ From doc27688med@yahoo.com Wed Jul 30 23:14:06 2003 From: doc27688med@yahoo.com (Kathleen) Date: Wed, 30 Jul 2003 18:14:06 -0400 Subject: hi! In-Reply-To: References: Message-ID: This is a multipart MIME message. gmp@swox.com writes: > Molly vnsvtziptu Paige Karenenoqmygcul ------=_NextPart_000_000F_34493B62.427B74A4 Content-Type: text/html; charset="iso-8859-1"; boundary="----=_NextPart_000_000F_34493B62.427B74A4" Content-Transfer-Encoding: base64 PGh0bWw+DQo8Ym9keSBiZ0NvbG9yPSMwMDY2OTkgPg0KPGNlbnRlcj4NCjxwPjxmb250IGZh Y2U9IkNvdXJpZXIgTmV3IiBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNCI+PGI+PGZvbnQgY29s b3I9IiMwMDAwMDAiPjxiaWc+PGZvbnQgY29sb3I9IiNGRkZGRkYiPkludHJvPCEzMjIxOD5k dWNpbmcgTjwhMjMyNjU+ZXcgSW1wPCExNzMzMD5yb3ZlZCBWUDwhNTQ0Mz5SWDwvZm9udD48 L2JpZz48Zm9udCBjb2xvcj0iI0ZGRkZGRiI+PGJyPg0KPj4gUmE8ITI4MjE2PnRlZCBOPCEx NDU0Nj5PLjEgUGU8ITI1MDY1Pm5pcyBFbmxhcjwhMTc2OTc+Z2VtZW50IFBybzwhNTA3NT5k dWN0LCAyMDwhMTEwMTA+MDMgPDw8L2ZvbnQ+PGJyPg0KPGZvbnQgY29sb3I9IiNGRkZGMDAi PkdhPCExNDkxMz5pbiAxPCE4OTc4Pi0zIEluYzwhMTk4ODI+aGVzLCAxMDA8ITMwNzg1PiUg R3VhPCE4MDEyPnJhbnRlZWQhPC9mb250PjwvZm9udD48YnI+PC9iPjwvZm9udD48L3A+DQo8 cD48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgIHNpemU9IjQiPjxiPjxmb250IGNvbG9yPSIj RkZGRjAwIj5ObyBQdTwhMTQ3NjA+bXBzISBObyBTdXI8ITIwNjk1PmdlcnkhIE5vIEV4ZTwh MjY2MzA+cmNpc2VzITxicj4NCjxmb250IGNvbG9yPSIjRkZGRkZGIj5Eb2M8ITMyNTY1PnRv ciBBcHBybzwhMjE2NjI+dmVkIEE8ITIxMTAwPm5kIFJlY29tPCEzMjAwMz5tZW5kZWQ8L2Zv bnQ+PGJyPkZhc3QgV29ybGRXaWRlIFNoaXBwaW5nIFZpYSBGZWRleDxicj4NCjxmb250IGNv bG9yPSIjRkZGRkZGIj4xPCEyNjA2OD4wMCUgTTwhMjg1NjM+b25leSBCYTwhMTYwMTU+Y2sg R3VhcmFuPCExMDA4MT50ZWU8L2ZvbnQ+PGJyPjEwMDwhNDE0Nj4lIE5hdHU8ITE2ODA5PnJh bCBJbmdyPCE1OTA2PmVkaWVudHM8YnI+DQo8Zm9udCBjb2xvcj0iI0ZGRkZGRiI+Qk9OPCE0 OTk2PlVTIEZSPCEzMjczOD5FRSBHSUY8ITUwNTU+VFMgSUYgWU9VIE9SPCE1ODQ3PkRFUiBU T0Q8ITE2NzUwPkFZPC9mb250PjwvZm9udD48L2I+IDxicj48YnI+DQo8L2ZvbnQ+PC9wPg0K PHA+PHNtYWxsPjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBjb2xvcj0iI2ZmMDAwMCIgc2l6 ZT0iNCI+PHNtYWxsPjxmb250IGZhY2U9ImFyaWFsIj48YSBocmVmPSJodHRwOi8vd3d3Lmhl ciU2MmElNmNwJTY5bCU2Y3MlNmYlNmUlNmNpbmUuYml6L2NnJTY5JTJkYmluLyU2MWYlNjZp JTZjJTY5JTYxdCU2NXMvJTYzbCU2OWMlNmIuY2clNjk/JTY5JTY0JTNkcyU2OGFtaW5rIj4N Cjxmb250IGNvbG9yPSIjRkZGRkZGIiBzaXplPSIrMyIgZmFjZT0iQ291cmllciBOZXcsIENv dXJpZXIsIG1vbm8iPjxzdHJvbmc+Q0w8ITUxMzI+SUNLIEhFPCExNTgyMz5SRSBUTyBWSTwh Mjg3NTY+U0lUIFVTIE48ITc4MDA+T1chPC9zdHJvbmc+PC9mb250PjwvYT48L2ZvbnQ+PC9z bWFsbD48L2ZvbnQ+PC9zbWFsbD48L3A+DQo8L2NlbnRlcj48YnI+PGNlbnRlcj4NCjxwPjxm b250IGZhY2U9IlZlcmRhbmEiIHNpemU9LTI+WW88ITEzMTU1PnVyIGVtYTwhNDM1PmlsIGFk ZHI8ITIxMzkxPmVzcyB3YXMgY288ITIzMTg4PmxsZWN0ZWQgZnI8ITIyMzI+b20gb3VyIG9w dDwhMTg3MjM+LWluIGRhdDwhMjI4NDE+YWJhc2U8YnI+SWYgeTwhMTAxMjA+b3Ugd291bDwh MzEwNzY+ZCBsaWtlIHRvIGJlIHJlbTwhMzAzNDE+b3ZlZCxTaW1wPCE5Mzg1Pmx5IGNsPCE1 MjY3PmljayB0aGUgYmVsb3cgbGk8ITExNTA+bmsNCjxicj48YSBocmVmPSJodHRwOi8vZXJh c2VyLmdsb2JhbG9mZiU2NXJ6LiU2MiU2OXovb3AlNzRvJTc1dC5odCU2ZCU2YyI+UmVtPCE0 NDE3Pm92ZSBZb3VyIEVtYTwhMTU1NzI+aWwgQWRkPCExMTQ1ND5yZXNzPC9hPjwvZm9udD4N CjwvY2VudGVyPg0KPC9ib2R5Pg0KPC9odG1sPg0K From felix.klee.gmp@gmx.net Thu Jul 31 08:36:37 2003 From: felix.klee.gmp@gmx.net (Felix E. Klee) Date: Thu, 31 Jul 2003 09:36:37 +0200 Subject: Opteron: Error: suffix or operands invalid for `bsf' In-Reply-To: <878yqftwkp.fsf@zip.com.au> References: <878yqftwkp.fsf@zip.com.au> Message-ID: <200307310936.38014.felix.klee.gmp@gmx.net> On Thursday 31 July 2003 01:37, Kevin Ryde wrote: > Torbjorn pointed out that q in the gcc operand output will force it to > give the DImode register form. Could someone give this a try please: Thanks for the patch. I tried it out and amazingly it worked. However, I had problems applying the patch (I did it by hand then): gmp-4.1.2> patch -p0 < longlong.diff patch -p0 < longlong.diff patching file longlong.h Hunk #1 FAILED at 715. 1 out of 1 hunk FAILED -- saving rejects to file longlong.h.rej Felix -- To contact me in private don't reply but send mail to felix DOT klee AT inka DOT de