Re: [mpir-devel] I need for a little project mpz_pow (mpz_t , mpz_t , mpz_t)
Fritzs Hero wrote: > Hello, > > I need a mpz_pow function. I heared about the problem of memory? So the only > reason why this function does not exist is because of memory (the system or > the processor memory cache?) > And if, why is mpz_powm here, when I definitly don't need this modulo (can it > be achieved with mpz_powm(?,?,?,0) to work like a normal pow? ) > Any kind of idear, how I achieve this pow calculation? Use void mpz_pow_ui (mpz_ptr, mpz_srcptr, unsigned long int) with the exponent being an 'unsigned long', i.e., the third parameter. -leif -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at https://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Fixed-size bignums
Robert Steed wrote: > How can I get integers of a specific size with MPIR? I need 512-bit > numbers to implement the SHA-512 cryptography algorithm. You mean modular arithmetic? Perhaps take a look at FLINT, its website (flintlib.org) is still down at the moment (perhaps until tomorrow) though. The source code (and documentation) is also on GitHub (wbhart/flint2/ IIRC). -leif -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at https://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] inaccurate results after assigning a passed variable
'Bill Hart' via mpir-devel wrote: > On 14 December 2015 at 11:41, <highcalcula...@gmail.com > <mailto:highcalcula...@gmail.com>> wrote: > > Alright, thanks! > > Does this mean that I have to mpf_set_default_prec always before the > first mpf_... declaration? > > > I would say so, yes. It sets the precision for any subsequent variables. > At least that is my understanding. Before calling mpf_init() that is. (The point of the declaration is irrelevant, other than it has to precede the call to mpf_init() of course.) There's also mpf_init2(), which takes the desired (minimal) precision as its second argument. -leif -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at https://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] MPIR-2.7.1 released
Jeroen Demeyer wrote: > For the record: the problem with Sage isn't caused by the strange > version number, it's a dependency issue. ... while with a proper .so version in *2.7.0* the problem wouldn't have popped up, just for the record. -leif -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] MPIR-2.7.1 released
'Bill Hart' via mpir-devel wrote: > Hmm, actually, I have > > LIBGMP_LT_CURRENT = 16 > LIBGMP_LT_REVISION = 1 > LIBGMP_LT_AGE = 6 > > I don't see where the 10 is coming from. Libtool madness. But the flaw w.r.t. the strange change is actually in the previous version of MPIR; the variable definitions in Makefile.am must not contain trailing whitespace (which is still the case for LIBGMPXX_LT_REVISION, and has been the case for LIBGMP_LT_REVISION in 2.7.0). -leif > On 19 November 2015 at 15:03, Bill Hart <goodwillh...@googlemail.com > <mailto:goodwillh...@googlemail.com>> wrote: > > That looks like a stupid bug on our part. > > I think the best way to fix this is to correct the .so version > number in our repo since the current numbering is useless. > > Bill. > > On 19 November 2015 at 14:28, Jeroen Demeyer <jdeme...@cage.ugent.be > <mailto:jdeme...@cage.ugent.be>> wrote: > > The .so version number changed from > > libmpir.so.16.0.0 (MPIR 2.7.0) > > to > > libmpir.so.10.6.1 (MPIR 2.7.1) > > which is strange in several ways (it's a downgrade; did the > version need to change at all for a bug-fix release?). It's > probably at the basis of the problems in Sage. > > > Jeroen. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Re: MPIR MinGW installation - undefined reference to '_imp____gmpz_init'
sisyph...@optusnet.com.au wrote: From: highcalcula...@gmail.com Sent: Friday, June 19, 2015 8:06 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] Re: MPIR MinGW installation - undefined reference to '_impgmpz_init' I would like to call it from Matlab using mex files, and there, the compiler complains that it does not see any .lib files (when compiling with mex ... -lmpir it looks for a file libmpir.lib) . [snip] Compiler answer: myfile.obj : error LNK2019: unresolved external symbol __imp___gmpf_init referenced in function void __cdecl myfile(double) That's interesting ... you've given the directive to link to -lmpir, no such library is found, but instead of croaking then and there the process continues anyway ? (I don't know Matlab at all.) Well, the non-presence of a library isn't necessarily a fatal error. Anyway, it's of course better to first keep going to potentially emit further error messages, in this case the unresolved symbols. [...] The fact that your object file is .obj instead of .o would indicate that it's built with a Microsoft Compiler - so, if need be, you should be able to build the requisite .lib file from the dll using your Microsoft Compiler installation's lib tool (as Bill has hinted). The 'error LNK2019' certainly comes from a M$ compiler (more precisely, its linker). You can also use GNU Binutils' 'dlltool' to create M$-compatible import libraries (*.LIB). -leif -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] NEWS: Resuming release process; job posting; new computer
Bill Hart wrote: New computer for MPIR development === Another piece of news is that we now have a new machine, courtesy of William Stein at the University of Washington Department of Mathematics, which we can use for MPIR development. It is a recent piledriver AMD at 3GHz. It has 16 cores, 96 GB Ram and heaps of very fast hard drive, with Ubuntu 14.04. It is very speedy for development. Hmmm, details? Except for the APUs, AMD and recent yields false. ;-) (AFAIK, the latest chips have been released in 2012 or early 2013; no Steamroller update, still 32 nm, and the server and high-end desktop chipsets are even older and outdated -- PCIe 2.0, SATA II (!) and USB 2.0.) Given 16 AMD cores and the clock speed, I guess this is a dual-8-core (3.1/3.2 GHz) Opteron 43xx/63xx machine. /rant Hopefully AMD will get a bit more competitive with Zen (dropping XOP which is broken in any GCC release although AMD themselves contributed, and the module concept, where pairs of cores share a couple of resources.) -leif -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] NEWS: Resuming release process; job posting; new computer
Bill Hart wrote: The machine I had been using was more than 5 years old and half the speed! Und einem geschenkten Gaul schaut man nicht ins Maul... I was just amused about the recent. -leif On 6 June 2015 at 16:51, leif not.rea...@online.de mailto:not.rea...@online.de wrote: Bill Hart wrote: New computer for MPIR development === Another piece of news is that we now have a new machine, courtesy of William Stein at the University of Washington Department of Mathematics, which we can use for MPIR development. It is a recent piledriver AMD at 3GHz. It has 16 cores, 96 GB Ram and heaps of very fast hard drive, with Ubuntu 14.04. It is very speedy for development. Hmmm, details? Except for the APUs, AMD and recent yields false. ;-) (AFAIK, the latest chips have been released in 2012 or early 2013; no Steamroller update, still 32 nm, and the server and high-end desktop chipsets are even older and outdated -- PCIe 2.0, SATA II (!) and USB 2.0.) Given 16 AMD cores and the clock speed, I guess this is a dual-8-core (3.1/3.2 GHz) Opteron 43xx/63xx machine. /rant Hopefully AMD will get a bit more competitive with Zen (dropping XOP which is broken in any GCC release although AMD themselves contributed, and the module concept, where pairs of cores share a couple of resources.) -leif -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] MPIR MinGW installation - undefined reference to '_imp____gmpz_init'
sisyph...@optusnet.com.au wrote: I was wondering more about name mangling and decorations. The C headers declare GMP's / MPIR's C functions with 'extern C' if __cplusplus is defined (i.e., when you're using them from C++ code), such that their names don't get mangled. According to the gmp manual at https://gmplib.org/manual/Headers-and-Libraries.html#Headers-and-Libraries C++ builds need to link to “-lgmpxx –lgmp” but I don’t know how that translates to mpir. '-lmpirxx -lmpir'. Unless you configured with '--enable-gmpcompat'. Still, as Bill said, this is only necessary if you really use the C++ interface of GMP/MPIR. -leif -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] MPIR MinGW installation - undefined reference to '_imp____gmpz_init'
highcalcula...@gmail.com wrote:
I managed to do the following via MinGW:
- run ./configure --disable-static --enable-shared
- make
- make check
(Is this all and now I can start using it or is a step missing?...)
You have to run 'make install' as well.
Depending on whether you want to /exclusively/ use MPIR (which is a
drop-in *replacement* of GMP) as opposed to having parallel, independent
installations of both GMP and MPIR, you might consider configuring MPIR
with '--enable-gmpcompat'.
Roughly speaking, the latter just creates aliases for the headers and
libraries, such that you don't have to modify code to switch between
MPIR and GMP, i.e., you can '#include gmp.h' and use '-lgmp'
regardless of whether you're actually using GMP or its fork, MPIR.
If you intend to use the C++ layer of GMP/MPIR, you also have to
configure with '--enable-cxx'. This is /not/ necessary if you just want
to use the C interface / library from within C++.
Now I want to compile the following program called mytest.cpp with
gcc; I tried typing g++ mytest.cpp -o mytest :
//---
#include mpir.h
#include gmp.h
#include gmp-impl.h
using namespace std;
int main ()
{
mpz_t z;
mpz_init(z);
return (0);
}
//---
You don't have to (and shouldn't) include both mpir.h and gmp.h, nor
gmp-impl.h. (It is sufficient to just include mpir.h, or, in case you
configured with '--enable-gmpcompat', just gmp.h.)
To link your program to the MPIR C library, you have to
g++ mytest.cpp -o mytest -lmpir
(Again, in case you configured MPIR with '--enable-gmpcompat', 'g++
mytest.cpp -o mytest -lgmp' also works.)
-leif
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Visual Studio 2013 and MPIR
Bill Hart wrote: Yes, can you confirm this bug exists in MPIR-2.7.0-alpha? I thought we fixed it ages ago. It's definitely fixed in MPIR 2.7.0-alpha12, and I *think* it already was in the very first alpha. Note that Dann tested the last /stable/ release with Cygwin, i.e., MPIR 2.6.0 (which still contained that bug). -leif On 28 April 2015 at 03:02, leif not.rea...@online.de mailto:not.rea...@online.de wrote: Dann Corbit wrote: [snip M$ Visual Studio 2013 stuff] Also, with Mingw, one test fails: … *FAIL: t-scan.exe* [...] = 1 of 64 tests failed See tests/mpz/test-suite.log Please report to http://groups.google.co.uk/group/mpir-devel/ = make[5]: *** [test-suite.log] Error 1 make[5]: Leaving directory `/f/math/mpir-2.6.0/tests/mpz' make[4]: *** [check-TESTS] Error 2 make[4]: Leaving directory `/f/math/mpir-2.6.0/tests/mpz' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/f/math/mpir-2.6.0/tests/mpz' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/f/math/mpir-2.6.0/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/f/math/mpir-2.6.0' make: *** [check] Error 2 I get zero failures building GMP with mingw. Try with GMP 4.3.2 for example... ;-) My environment. Gcc version: $ gcc --version gcc.exe (x86_64-posix-seh-rev1, Built by MinGW-W64 project) 4.9.2 [...] There had been a bug in t-scan (i.e., just the test suite, not the library) for a long time which incidentally only popped up with GCC 4.8.0 and later versions; this has been fixed in GMP a while ago (don't recall which exact version) and also in MPIR [1], 2.7.0 IIRC. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] MPIR's configure fails with GCC 5.x
Bill Hart wrote: Thanks Leif! Forwarded from Sage's trac: Replying to jdemeyer: Why not unconditionally use static __inline__? I think that should work on all compilers. Thought of that, too (already when we were fixing the test for clang), but this way it's more explicit, and more importantly doesn't change the test at all for older compilers. After all, upstream will decide... Opinions? -leif On 26 April 2015 at 19:41, leif not.rea...@online.de mailto:not.rea...@online.de wrote: leif wrote: Similar to the issues we already had with clang, and as easy to fix. See http://trac.sagemath.org/ticket/18247 for details. Upstream patch attached (only fixes acinclude.m4, not the generated files, i.e., 'configure'). -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Visual Studio 2013 and MPIR
Bill Hart wrote: On 28 April 2015 at 21:20, Dann Corbit dcor...@connx.com mailto:dcor...@connx.com wrote: Since 2.6.0 is released, I suggest a back-patch to make a 2.6.1 so that the test does not fail. Sorry, we don't have the resources to make back patches for old versions of MPIR. We barely have the resources to make new releases! Well, you could perhaps update http://mpir.org with a short list of known issues for 2.6.0 (probably even with links to github, say). -leif -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Visual Studio 2013 and MPIR
Dann Corbit wrote: [snip M$ Visual Studio 2013 stuff] Also, with Mingw, one test fails: … *FAIL: t-scan.exe* [...] = 1 of 64 tests failed See tests/mpz/test-suite.log Please report to http://groups.google.co.uk/group/mpir-devel/ = make[5]: *** [test-suite.log] Error 1 make[5]: Leaving directory `/f/math/mpir-2.6.0/tests/mpz' make[4]: *** [check-TESTS] Error 2 make[4]: Leaving directory `/f/math/mpir-2.6.0/tests/mpz' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/f/math/mpir-2.6.0/tests/mpz' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/f/math/mpir-2.6.0/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/f/math/mpir-2.6.0' make: *** [check] Error 2 I get zero failures building GMP with mingw. Try with GMP 4.3.2 for example... ;-) My environment. Gcc version: $ gcc --version gcc.exe (x86_64-posix-seh-rev1, Built by MinGW-W64 project) 4.9.2 [...] There had been a bug in t-scan (i.e., just the test suite, not the library) for a long time which incidentally only popped up with GCC 4.8.0 and later versions; this has been fixed in GMP a while ago (don't recall which exact version) and also in MPIR [1], 2.7.0 IIRC. -leif [1] https://github.com/wbhart/mpir/commit/cd371dfbaca8a73806e7e304fdb18ad5866c15cc -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] MPIR's configure fails with GCC 5.x
leif wrote:
Similar to the issues we already had with clang, and as easy to fix.
See http://trac.sagemath.org/ticket/18247 for details.
Upstream patch attached (only fixes acinclude.m4, not the generated
files, i.e., 'configure').
-leif
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.
Fix 'configure' test that fails with GCC 5.x just because it now defaults
to standard C inline semantics. (See Sage trac #18247.)
--- mpir-2.7.0/acinclude.m4 2014-09-14 21:59:12.0 +0200
+++ mpir-2.7.0/acinclude.m4 2015-04-26 16:26:10.231054407 +0200
@@ -584,6 +584,9 @@
#if defined(__GNUC__) !defined(__clang__)
typedef unsigned long long t1;typedef t1*t2;
+#if defined(__GNUC_STDC_INLINE__)Â /* e.g. GCC 5.x defaults to this, not __GNUC_GNU_INLINE__ */
+extern
+#endif
__inline__ t1 e(t2 rp,t2 up,int n,t1 v0)
{t1 c,x,r;int i;if(v0){c=1;for(i=1;in;i++){x=up[i];r=x+1;rp[i]=r;}}return c;}
f(){static const struct{t1 n;t1 src[9];t1 want[9];}d[]={{1,{0},{1}},};t1 got[9];int i;
Re: [mpir-devel] MPIR's configure fails with GCC 5.x
leif wrote:
leif wrote:
Similar to the issues we already had with clang, and as easy to fix.
See http://trac.sagemath.org/ticket/18247 for details.
Upstream patch attached (only fixes acinclude.m4, not the generated
files, i.e., 'configure').
Sorry, just noticed some crap characters in the patch.
Fixed one attached.
-leif
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.
Fix 'configure' test that fails with GCC 5.x just because it now defaults
to standard C inline semantics. (See Sage trac #18247.)
--- mpir-2.7.0/acinclude.m4 2014-09-14 21:59:12.0 +0200
+++ mpir-2.7.0/acinclude.m4 2015-04-26 16:26:10.231054407 +0200
@@ -584,6 +584,9 @@
#if defined(__GNUC__) !defined(__clang__)
typedef unsigned long long t1;typedef t1*t2;
+#if defined(__GNUC_STDC_INLINE__) /* e.g. GCC 5.x defaults to this, not __GNUC_GNU_INLINE__ */
+extern
+#endif
__inline__ t1 e(t2 rp,t2 up,int n,t1 v0)
{t1 c,x,r;int i;if(v0){c=1;for(i=1;in;i++){x=up[i];r=x+1;rp[i]=r;}}return c;}
f(){static const struct{t1 n;t1 src[9];t1 want[9];}d[]={{1,{0},{1}},};t1 got[9];int i;
[mpir-devel] MPIR's configure fails with GCC 5.x
Similar to the issues we already had with clang, and as easy to fix. (I grabbed the first GCC 5.x release candidate -- while the tarball [1] is named 5.1.0-RC-20150412*, it identifies as GCC 5.0.1 (prerelease), in accordance with *the subject* of its announcement message [2], while GCC's home page [3] and the message itself again speak of 5.1.) After fixing 'configure', MPIR's test suite passes for me, at least on a Haswell CPU (on which MPIR decides to use '-march=k8' though ;-) ). See http://trac.sagemath.org/ticket/18247 for details. -leif * Just noticed there's meanwhile also 5.0.1-RC-20150418. B) [1] ftp://gcc.gnu.org/pub/gcc/snapshots/5.1.0-RC-20150412/ [2] https://gcc.gnu.org/ml/gcc/2015-04/msg00145.html [3] https://gcc.gnu.org/ -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] How to add mpir (non gmpcompat) to existing projects that used gmp-only before?
On 03/06/2015 08:19 PM, Simon Sobisch wrote: GnuCOBOL currently only works with mpir if gmpcompat is used. Could you perhaps elaborate your problem (?) in configuring MPIR with '--enable-gmpcompat'? If mpir is configured with --enable-gmpcompat everything works. Ok. But as GnuCOBOL is sometimes installed on systems where both gmp and mpir are already installed before (sometimes mpir is just for testing, sometimes mpir has both the header file and the library while gmp has only the library available) it would be nice to link against libmpir (and using the appropriate header). I wouldn't really support that (other than by '--with-gmp=...' and the like). If /building/ GnuCOBOL needs the development package (with headers) of (either) GMP or MPIR, you should simply require that, i.e., in the latter case MPIR built with '--enable-gmpcompat' (but see also below). To /use/ GnuCOBOL one presumably only needs the library (libgmp*). Having both MPIR and GMP installed at the same time isn't much different to having different versions of GMP (or MPIR) installed, with all compile-time and run-time implications. MPIR's '--enable-gmpcompat' doesn't [yet, at least ;-) ] do anything magic AFAIK; it simply creates additional symbolic links or copies such that filenames match. To say it short: it would be nice to not force people to (re-)build mpir with --enable-gmpcompat. As mentioned, renaming or copying MPIR's files (probably also specifying a different path when configuring GnuCOBOL) if needed should be sufficient (and IMHO isn't too hard to ask for). You could of course build some magic into GnuCOBOL's 'configure', but I don't think it's worth the effort, compared to adding a few lines to the installation instructions... The new configure already checks for libmpir and mpir.h if libgmp or gmp.h is not found and the building works but I'm unsure about the best way to do it. For mpir.h, you could simply create a gmp.h which includes mpir.h if necessary instead of changing source code; using libmpir* instead of libgmp* presumably only involves messing around with some Makefile variables (but sounds like you already managed that). However, note that a (dynamically linked) GnuCOBOL binary built that way then requires libmpir, shifting the problem to distribution, or closer to the end user I imagine. -leif -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] --enable-fat fails on 32-bit linux
On 02/18/2015 10:44 PM, Bill Hart wrote:
Thanks for the feedback. I'll add it to the ticket.
I don't know off the top of my head what could be going wrong.
The attached patch works for me on x86 as well as x86_64 with ABI=32.
(cf. http://trac.sagemath.org/ticket/17806#comment:6)
Cheers,
-leif
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.
--- mpir-2.7.0-alpha12/mpn/x86/fat/fat.c.orig 2014-09-14 21:59:13.0 +0200
+++ mpir-2.7.0-alpha12/mpn/x86/fat/fat.c 2015-02-20 20:16:13.909300216 +0100
@@ -37,6 +37,8 @@
long __gmpn_cpuid __GMP_PROTO ((char dst[12], int id));
struct cpuvec_t __gmpn_cpuvec = {
+ __MPN(add_err1_n_init),
+ __MPN(add_err2_n_init),
__MPN(add_n_init),
__MPN(addmul_1_init),
__MPN(copyd_init),
@@ -55,11 +57,14 @@
__MPN(modexact_1c_odd_init),
__MPN(mul_1_init),
__MPN(mul_basecase_init),
+ __MPN(mulmid_basecase_init),
__MPN(preinv_divrem_1_init),
__MPN(preinv_mod_1_init),
__MPN(redc_1_init),
__MPN(rshift_init),
__MPN(sqr_basecase_init),
+ __MPN(sub_err1_n_init),
+ __MPN(sub_err2_n_init),
__MPN(sub_n_init),
__MPN(submul_1_init),
__MPN(sumdiff_n_init),
@@ -102,6 +107,8 @@
#define CPUSETUP_nehalem CPUVEC_SETUP_nehalem
#define CPUSETUP_westmere CPUVEC_SETUP_nehalem
#define CPUSETUP_sandybridge CPUVEC_SETUP_nehalem
+#define CPUSETUP_ivybridge CPUVEC_SETUP_nehalem
+#define CPUSETUP_haswell CPUVEC_SETUP_nehalem
#define CPUSETUP_atom CPUVEC_SETUP_p6;CPUVEC_SETUP_p6_mmx;CPUVEC_SETUP_p6_p3mmx
#define CPUSETUP_nano CPUVEC_SETUP_p6;CPUVEC_SETUP_p6_mmx;CPUVEC_SETUP_p6_p3mmx
#define CPUSETUP_pentium4 CPUVEC_SETUP_pentium4;CPUVEC_SETUP_pentium4_mmx;CPUVEC_SETUP_pentium4_sse2
@@ -116,6 +123,7 @@
#define CPUSETUP_k102 CPUVEC_SETUP_k7;CPUVEC_SETUP_k7_mmx;CPUVEC_SETUP_k7_mmx_k8;CPUVEC_SETUP_k7_mmx_k8_k10;CPUVEC_SETUP_k7_mmx_k8_k10_k102
#define CPUSETUP_k103 CPUVEC_SETUP_k7;CPUVEC_SETUP_k7_mmx;CPUVEC_SETUP_k7_mmx_k8;CPUVEC_SETUP_k7_mmx_k8_k10;CPUVEC_SETUP_k7_mmx_k8_k10_k102
#define CPUSETUP_bulldozer CPUVEC_SETUP_k7;CPUVEC_SETUP_k7_mmx;CPUVEC_SETUP_k7_mmx_k8;CPUVEC_SETUP_k7_mmx_k8_k10;CPUVEC_SETUP_k7_mmx_k8_k10_k102
+#define CPUSETUP_piledriver CPUVEC_SETUP_k7;CPUVEC_SETUP_k7_mmx;CPUVEC_SETUP_k7_mmx_k8;CPUVEC_SETUP_k7_mmx_k8_k10;CPUVEC_SETUP_k7_mmx_k8_k10_k102
#define CPUSETUP_bobcat CPUVEC_SETUP_k7;CPUVEC_SETUP_k7_mmx;CPUVEC_SETUP_k7_mmx_k8;CPUVEC_SETUP_k7_mmx_k8_k10;CPUVEC_SETUP_k7_mmx_k8_k10_k102
#define CPUSETUP_viac3 do{}while(0)
#define CPUSETUP_viac32 do{}while(0)
Re: [mpir-devel] Re: MPIR-2.7.0-alpha7 available for testing
On 25.06.2014 15:27, Bill Hart wrote: To me, that looks like it might be a gcc bug. Perhaps we can find some kind of workaround though. ANSI string concatenation perhaps? Wasn't that already part of ISO C90? ;-) Anyway, I can't reproduce this with vanilla FSF GCC 4.8.3 (on Linux, haven't tried Darwin), although any version of GCC I tried inserts a blank with -E, unless also '-traditional-cpp' is given; see also: -traditional -traditional-cpp Formerly, these options caused GCC to attempt to emulate a pre-standard C compiler. They are now only supported with the -E switch. The preprocessor continues to support a pre-standard mode. See the GNU CPP manual for details. So either some Darwin weirdness, or the homebrewed GCC is (severely) broken... -leif I made a ticket for this one. Bill. On 25 June 2014 14:27, Daniel R. Grayson d...@math.uiuc.edu mailto:d...@math.uiuc.edu wrote: With mpir-2.7.0-alpha7.tar.bz2 and ./configure --enable-assert CC=/Users/dan/local/bin/gcc make all check where /Users/dan/local/bin/gcc is gcc (Homebrew gcc48 4.8.3 --enable-fortran) 4.8.3 I get some macro weirdness: libtool: compile: /Users/dan/local/bin/gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul_fft -m64 -O2 -march=k8 -mtune=k8 -c mul_fft.c -fno-common -DPIC -o .libs/mul_fft.o In file included from mul_fft.c:3:0: ../gmp-impl.h:160:40: error: expected ')' before 'L' #define CNST_LIMB(C) ((mp_limb_t) C/**/L) ^ On Monday, June 16, 2014 10:35:58 AM UTC-4, Bill Hart wrote: I have uploaded alpha7 to our website (http://mpir.org). -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Re: MPIR-2.7.0-alpha7 available for testing
On 26.06.2014 09:26, leif wrote: On 25.06.2014 15:27, Bill Hart wrote: To me, that looks like it might be a gcc bug. Perhaps we can find some kind of workaround though. ANSI string concatenation perhaps? Wasn't that already part of ISO C90? ;-) Anyway, I can't reproduce this with vanilla FSF GCC 4.8.3 (on Linux, haven't tried Darwin), although any version of GCC I tried inserts a blank with -E, unless also '-traditional-cpp' is given; see also: -traditional -traditional-cpp Formerly, these options caused GCC to attempt to emulate a pre-standard C compiler. They are now only supported with the -E switch. The preprocessor continues to support a pre-standard mode. See the GNU CPP manual for details. So either some Darwin weirdness, or the homebrewed GCC is (severely) broken... Or rather, where does __GMP_HAVE_TOKEN_PASTE get defined? A quick grep didn't enlight me... Ok, in gmp-h.in, we have: #if defined (__STDC__) \ || defined (__cplusplus) \ || defined (_AIX) \ || defined (__DECC) \ || (defined (__mips) defined (_SYSTYPE_SVR4)) \ || defined (_MSC_VER) \ || defined (_WIN32) #define __GMP_HAVE_CONST1 #define __GMP_HAVE_PROTOTYPES 1 #define __GMP_HAVE_TOKEN_PASTE 1 #else #define __GMP_HAVE_CONST0 #define __GMP_HAVE_PROTOTYPES 0 #define __GMP_HAVE_TOKEN_PASTE 0 #endif So the homebrewed GCC apparently doesn't define __STDC__ ?! That's usually something 'configure' should check, although I think *any* compiler able to build MPIR should have it... -leif I made a ticket for this one. Bill. On 25 June 2014 14:27, Daniel R. Grayson d...@math.uiuc.edu mailto:d...@math.uiuc.edu wrote: With mpir-2.7.0-alpha7.tar.bz2 and ./configure --enable-assert CC=/Users/dan/local/bin/gcc make all check where /Users/dan/local/bin/gcc is gcc (Homebrew gcc48 4.8.3 --enable-fortran) 4.8.3 I get some macro weirdness: libtool: compile: /Users/dan/local/bin/gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul_fft -m64 -O2 -march=k8 -mtune=k8 -c mul_fft.c -fno-common -DPIC -o .libs/mul_fft.o In file included from mul_fft.c:3:0: ../gmp-impl.h:160:40: error: expected ')' before 'L' #define CNST_LIMB(C) ((mp_limb_t) C/**/L) ^ On Monday, June 16, 2014 10:35:58 AM UTC-4, Bill Hart wrote: I have uploaded alpha7 to our website (http://mpir.org). -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Re: MPIR-2.7.0-alpha7 available for testing
On 26.06.2014 11:23, Jakob Kroeker wrote: I get the same macro weirdness for gcc 4.4.7 and 4.7.3 on Scientific Linux 6.5 What does gcc -E -dM -x c /dev/null | grep STDC and/or gcc -std=gnu99 -E -dM -x c /dev/null | grep STDC give? -leif Am Mittwoch, 25. Juni 2014 14:27:09 UTC+2 schrieb Daniel R. Grayson: With mpir-2.7.0-alpha7.tar.bz2 and ./configure --enable-assert CC=/Users/dan/local/bin/gcc make all check where /Users/dan/local/bin/gcc is gcc (Homebrew gcc48 4.8.3 --enable-fortran) 4.8.3 I get some macro weirdness: libtool: compile: /Users/dan/local/bin/gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul_fft -m64 -O2 -march=k8 -mtune=k8 -c mul_fft.c -fno-common -DPIC -o .libs/mul_fft.o In file included from mul_fft.c:3:0: ../gmp-impl.h:160:40: error: expected ')' before 'L' #define CNST_LIMB(C) ((mp_limb_t) C/**/L) ^ On Monday, June 16, 2014 10:35:58 AM UTC-4, Bill Hart wrote: I have uploaded alpha7 to our website (http://mpir.org). This fixes some (severe) problems with compiling against GMP-ECM. It also fixes numerous compiler warnings reported by Leif Lionhardy. The changes affect all platforms, including 32 and 64 bit. I was unable to come up with robust fixes for the following two, so I have made tickets for them to be fixed in a later release of MPIR. https://github.com/wbhart/mpir/issues/134 https://github.com/wbhart/mpir/issues/133 Bill. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Re: MPIR-2.7.0-alpha7 available for testing
On 26.06.2014 11:56, Jakob Kroeker wrote: gcc -E -dM -x c /dev/null | grep STDC : #define __STDC_HOSTED__ 1 #define __STDC__ 1 gcc -std=gnu99 -E -dM -x c /dev/null | grep STDC : #define __STDC_HOSTED__ 1 #define __STDC_UTF_16__ 1 #define __STDC_VERSION__ 199901L #define __GNUC_STDC_INLINE__ 1 #define __STDC_UTF_32__ 1 #define __STDC__ 1 Hmmm, then __GMP_HAVE_TOKEN_PASTE should be defined to 1... 8-/ ...deep thinking... Does it also happen if you configure with (in addition) '--enable-gmpcompat'? -leif Am Donnerstag, 26. Juni 2014 11:34:48 UTC+2 schrieb leif: On 26.06.2014 11:23, Jakob Kroeker wrote: I get the same macro weirdness for gcc 4.4.7 and 4.7.3 on Scientific Linux 6.5 What does gcc -E -dM -x c /dev/null | grep STDC and/or gcc -std=gnu99 -E -dM -x c /dev/null | grep STDC give? -leif Am Mittwoch, 25. Juni 2014 14:27:09 UTC+2 schrieb Daniel R. Grayson: With mpir-2.7.0-alpha7.tar.bz2 and ./configure --enable-assert CC=/Users/dan/local/bin/gcc make all check where /Users/dan/local/bin/gcc is gcc (Homebrew gcc48 4.8.3 --enable-fortran) 4.8.3 I get some macro weirdness: libtool: compile: /Users/dan/local/bin/gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_mul_fft -m64 -O2 -march=k8 -mtune=k8 -c mul_fft.c -fno-common -DPIC -o .libs/mul_fft.o In file included from mul_fft.c:3:0: ../gmp-impl.h:160:40: error: expected ')' before 'L' #define CNST_LIMB(C) ((mp_limb_t) C/**/L) ^ -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Re: MPIR-2.7.0-alpha7 available for testing
On 26.06.2014 12:41, Jakob Kroeker wrote: Does it also happen if you configure with (in addition) '--enable-gmpcompat'? With '--enable-gmpcompat' it compiles. Fine. If you don't want '--enable-gmpcompat', replace #include gmp.h by #include mpir.h in mpn/generic/mul_fft.c (in the MPIR source tree). -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Re: MPIR-2.7.0 alpha8
Bill Hart wrote:
Thanks. I'll look into it and see if it is something recent or a
compiler issue.
Presumably not the latter, as the same tests fail not only with GCC
4.8.x and GCC 4.9.0, but also Clang (3.4.1)...
I do recall testing with --enable-assert and no issues appeared, but I
might have screwed something up since.
... but only if I configure with ('--enable-assert' and)
'--build=x86_64-linux-gnu' (= '-march=k8 -mtune=k8', and, more
importantly I guess, MPN_PATH=x86_64 generic).
And by the way, in the function we have:
ASSERT(n 0);
...
if (n == 0)
return 0;
...
-leif
On 26 June 2014 22:24, Jakob Kroeker kroe...@uni-math.gwdg.de
mailto:kroe...@uni-math.gwdg.de wrote:
I reported the same failure in a different thread.
Here is the logfile output:
FAIL: t-butterfly_sqrt2 (exit: 134)
===
sumdiff_n.c:30: GNU MP assertion failed: n 0
FAIL: t-fft_ifft_mfa_trunc_sqrt2 (exit: 134)
sumdiff_n.c:30: GNU MP assertion failed: n 0
FAIL: t-fft_ifft_trunc_sqrt2 (exit: 134)
sumdiff_n.c:30: GNU MP assertion failed: n 0
FAIL: t-mul_fft_main (exit: 134)
sumdiff_n.c:30: GNU MP assertion failed: n 0
FAIL: t-mul_mfa_trunc_sqrt2 (exit: 134)
===
sumdiff_n.c:30: GNU MP assertion failed: n 0
FAIL: t-mul_trunc_sqrt2 (exit: 134)
===
sumdiff_n.c:30: GNU MP assertion failed: n 0
Jack
Am Donnerstag, 26. Juni 2014 22:08:14 UTC+2 schrieb Bill Hart:
Could you give me the contents of the log files for these tests.
This gcc must be broken. I can't see how any of those tests can
fail, unless I've screwed something up accidentally somewhere. They
pass on my machine for example and haven't changed since 2.6.0.
Bill.
On 26 June 2014 19:42, Daniel R. Grayson d...@math.uiuc.edu
mailto:d...@math.uiuc.edu wrote:
Mac OS X, using gcc (Homebrew gcc48 4.8.3 --enable-fortran) 4.8.3
and configuring with --enable-assert:
FAIL: t-butterfly_sqrt2
FAIL: t-fft_ifft_mfa_trunc_sqrt2
FAIL: t-fft_ifft_trunc_sqrt2
FAIL: t-mul_fft_main
FAIL: t-mul_mfa_trunc_sqrt2
FAIL: t-mul_trunc_sqrt2
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] MPIR-2.7.0-alpha7 available for testing
Bill Hart wrote: Leif, is this only exposed when the user manually sets an optimisation level of -O3 or is it the default when MPIR builds on this system? Nope, as mentioned in my previous post: ;-) [...] unfortunately (also) the library gets miscompiled. When I build the library with XOP instructions enabled and the test suite without, I'm getting the same five test failures with GCC 4.8.3, one less (i.e., only two) with GCC 4.9.0. Note however that this happens only with '-O3', otherwise GCC hardly ever emits XOP instructions at all (in my experience at least). I would say that if you compile with -O3 you are asking for trouble. Well, no risk, no fun. Actually the only flaw (in [recent] vanilla FSF GCCs) with '-O3' I'm currently aware of (or running into). (Ubuntu's and Debian's GCCs are similarly broken, but at least Ubuntu's in addition to other bugs...) But if we do that by default, that's a different story. I'd rather say it's something to mention in the release notes; if the user specifies C/CXXFLAGS, MPIR's currently get dropped anyway, so adding '-mno-xop' on bdver* wouldn't really help, although you could of course issue a warning. Or /prepend/ MPIR's to user-specified ones... (That's what we currently do in Sage, but to achieve this, we have to dry-run MPIR's 'configure' once with CFLAGS and CXXFLAGS temporarily unset.) -leif On 16 June 2014 22:22, leif not.rea...@online.de mailto:not.rea...@online.de wrote: Bill Hart wrote: I have uploaded alpha7 to our website (http://mpir.org). Just for the record: MPIR's test suite now exposes GCC's XOP-brokenness (I *think* that's new in alpha7, but probably already in alpha5 or 6). AFAICT, there's not a single GCC version (supporting bdver*) that /isn't/ in some way broken w.r.t. XOP instructions, but so far MPIR wasn't affected (and GMP still isn't). So be prepared for respective bug reports... ;-) (Haven't checked yet whether just the test suite miscompiles, but I at least hope the library itself isn't affected.) -leif GCC 4.9.0, -march=bdver2 -mtune=bdver2 -O3 (all pass with -mno-xop): PASS: t-inv_divappr_q /bin/bash: line 1: 12856 Aborted $tst t-inv_divappr_q_n.log-t 21 FAIL: t-inv_divappr_q_n /bin/bash: line 1: 12887 Aborted $tst t-invert.log-t 21 FAIL: t-invert PASS: t-iord_u PASS: t-lorrshift1 PASS: t-matrix22 /bin/bash: line 1: 13011 Aborted $tst t-mp_bases.log-t 21 FAIL: t-mp_bases PASS: t-mullow_basecase PASS: t-mullowhigh PASS: t-mulmid PASS: t-mulmod_2expm1 PASS: t-mulmod_2expp1 PASS: t-neg PASS: t-perfsqr PASS: t-redc_1 PASS: t-sb_bdiv_q PASS: t-sb_bdiv_qr PASS: t-sb_div_q PASS: t-sb_div_qr PASS: t-sb_divappr_q PASS: t-scan PASS: t-subadd_n PASS: t-tdiv_q PASS: t-tdiv_qr PASS: st_fat PASS: st_instrument ==__==__= 3 of 49 tests failed See tests/mpn/test-suite.log Please report to http://groups.google.co.uk/__group/mpir-devel/ http://groups.google.co.uk/group/mpir-devel/ ==__==__= ==__ MPIR 2.7.0: tests/mpn/test-suite.log ==__ 3 of 49 tests failed. .. contents:: :depth: 2 FAIL: t-inv_divappr_q_n (exit: 134) ==__= failed: nn = 3084, dn = 1542, qn = 1542, rn = 2312 --__--__--- GCC 4.8.3, -march=bdver2 -mtune=bdver2 -O3 (all pass with -mno-xop): PASS: t-inv_div_q /bin/bash: line 1: 19233 Aborted $tst t-inv_div_qr.log-t 21 FAIL: t-inv_div_qr /bin/bash: line 1: 19264 Aborted $tst t-inv_div_qr_n.log-t 21 FAIL: t-inv_div_qr_n /bin/bash: line 1: 19295 Aborted $tst t-inv_divappr_q.log-t 21 FAIL: t-inv_divappr_q /bin/bash: line 1: 19326 Aborted $tst t-inv_divappr_q_n.log-t 21 FAIL: t-inv_divappr_q_n /bin/bash: line 1: 19357 Aborted $tst t-invert.log-t 21 FAIL: t-invert PASS: t-iord_u PASS: t-lorrshift1 PASS: t-matrix22 PASS: t-mp_bases PASS: t-mullow_basecase PASS: t-mullowhigh PASS: t-mulmid PASS: t-mulmod_2expm1 PASS: t-mulmod_2expp1 PASS: t-neg PASS: t-perfsqr PASS: t-redc_1 PASS: t-sb_bdiv_q PASS: t-sb_bdiv_qr PASS: t-sb_div_q PASS: t-sb_div_qr PASS: t-sb_divappr_q PASS: t-scan PASS: t-subadd_n PASS: t-tdiv_q PASS: t-tdiv_qr PASS: st_fat PASS: st_instrument ==__==__= 5 of 49 tests failed
Re: [mpir-devel] MPIR-2.7.0-alpha7 available for testing
leif wrote:
Bill Hart wrote:
Leif, is this only exposed when the user manually sets an optimisation
level of -O3 or is it the default when MPIR builds on this system?
P.S.: W.r.t. this sytem:
Any AMD Opteron 62xx/63xx, FX-{4,6,8}[13]xx (and the Devil's Canyon
9xxx or whatever they're called) as well as presumably the Kaveri APUs,
with any GCC = 4.6, and '-O3' (and '-march=...' without '-mno-xop').
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.
[mpir-devel] Fwd: Error Building sage-6.2: Error installing package mpir-2.6.0.p4
Ever seen that (or similar)? %) I'll ask for the full MPIR build log... -leif Original Message Subject:Error Building sage-6.2: Error installing package mpir-2.6.0.p4 Date: Tue, 17 Jun 2014 03:38:57 -0700 (PDT) From: Yun Peng Lin yunpeng...@hotmail.com Reply-To: sage-supp...@googlegroups.com To: sage-supp...@googlegroups.com Newsgroups: gmane.comp.mathematics.sage.support I'm trying to build Sage 6.2 (latest version from http://www.sagemath.org/) from the source distribution. After running make, it built for an hour before failing when trying to build package: mpir-2.6.0.p4. A section of the mpir-2.6.0.p4 log file containing the error is below. I'm trying to make sage in redhat version 5.7 Tikanga. The system is 64Bit, CPU is an Intel Xeon processor. Any help would be greatly appreciated. Many thanks! //---mpir-2.6.0.p4.logExtract- gp-xstrdup.o: In function `gnu_dev_minor': xstrdup.c:(.text+0x29): multiple definition of `gnu_dev_minor' genperf.o:genperf.c:(.text+0x29): first defined here gp-xstrdup.o: In function `gnu_dev_makedev': xstrdup.c:(.text+0x46): multiple definition of `gnu_dev_makedev' genperf.o:genperf.c:(.text+0x46): first defined here collect2: error: ld returned 1 exit status make[6]: *** [genperf] Error 1 make[6]: Leaving directory `/home/user_test/test/sage-6.2/local/var/tmp/sage/build/mpir-2.6.0.p4/src/yasm' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/home/user_test/test/sage-6.2/local/var/tmp/sage/build/mpir-2.6.0.p4/src' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/user_test/test/sage-6.2/local/var/tmp/sage/build/mpir-2.6.0.p4/src' Error building MPIR. real1m24.272s user0m56.834s sys 0m26.969s Error installing package mpir-2.6.0.p4 Please email sage-devel (http://groups.google.com/group/sage-devel) explaining the problem and including the relevant part of the log file /home/user_test/test/sage-6.2/logs/pkgs/mpir-2.6.0.p4.log Describe your computer, operating system, etc. If you want to try to fix the problem yourself, *don't* just cd to /home/user_test/test/sage-6.2/local/var/tmp/sage/build/mpir-2.6.0.p4 and type 'make' or whatever is appropriate. Instead, the following commands setup all environment variables correctly and load a subshell for you to debug the error: (cd '/home/user_test/test/sage-6.2/local/var/tmp/sage/build/mpir-2.6.0.p4' '/home/user_test/test/sage-6.2/sage' --sh) When you are done debugging, you can type exit to leave the subshell. -- You received this message because you are subscribed to the Google Groups sage-support group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com mailto:sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-supp...@googlegroups.com mailto:sage-supp...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Fwd: Error Building sage-6.2: Error installing package mpir-2.6.0.p4
leif wrote: Ever seen that (or similar)? %) I'll ask for the full MPIR build log... P.S.: As Tikanga is dead old (and hence presumably a dead old GCC was used) and regarding the build time before the error occurred, I guess Sage's GCC 4.7.3 first got built, so I think the error refers to (re)building MPIR with that. -leif Original Message Subject: Error Building sage-6.2: Error installing package mpir-2.6.0.p4 Date: Tue, 17 Jun 2014 03:38:57 -0700 (PDT) From: Yun Peng Lin yunpeng...@hotmail.com Reply-To: sage-supp...@googlegroups.com To: sage-supp...@googlegroups.com Newsgroups: gmane.comp.mathematics.sage.support I'm trying to build Sage 6.2 (latest version from http://www.sagemath.org/) from the source distribution. After running make, it built for an hour before failing when trying to build package: mpir-2.6.0.p4. A section of the mpir-2.6.0.p4 log file containing the error is below. I'm trying to make sage in redhat version 5.7 Tikanga. The system is 64Bit, CPU is an Intel Xeon processor. Any help would be greatly appreciated. Many thanks! //---mpir-2.6.0.p4.logExtract- gp-xstrdup.o: In function `gnu_dev_minor': xstrdup.c:(.text+0x29): multiple definition of `gnu_dev_minor' genperf.o:genperf.c:(.text+0x29): first defined here gp-xstrdup.o: In function `gnu_dev_makedev': xstrdup.c:(.text+0x46): multiple definition of `gnu_dev_makedev' genperf.o:genperf.c:(.text+0x46): first defined here collect2: error: ld returned 1 exit status make[6]: *** [genperf] Error 1 make[6]: Leaving directory `/home/user_test/test/sage-6.2/local/var/tmp/sage/build/mpir-2.6.0.p4/src/yasm' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/home/user_test/test/sage-6.2/local/var/tmp/sage/build/mpir-2.6.0.p4/src' make[4]: *** [all] Error 2 make[4]: Leaving directory `/home/user_test/test/sage-6.2/local/var/tmp/sage/build/mpir-2.6.0.p4/src' Error building MPIR. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] MPIR-2.7.0-alpha7 available for testing
Bill Hart wrote: I have uploaded alpha7 to our website (http://mpir.org). Just for the record: MPIR's test suite now exposes GCC's XOP-brokenness (I *think* that's new in alpha7, but probably already in alpha5 or 6). AFAICT, there's not a single GCC version (supporting bdver*) that /isn't/ in some way broken w.r.t. XOP instructions, but so far MPIR wasn't affected (and GMP still isn't). So be prepared for respective bug reports... ;-) (Haven't checked yet whether just the test suite miscompiles, but I at least hope the library itself isn't affected.) -leif GCC 4.9.0, -march=bdver2 -mtune=bdver2 -O3 (all pass with -mno-xop): PASS: t-inv_divappr_q /bin/bash: line 1: 12856 Aborted $tst t-inv_divappr_q_n.log-t 21 FAIL: t-inv_divappr_q_n /bin/bash: line 1: 12887 Aborted $tst t-invert.log-t 21 FAIL: t-invert PASS: t-iord_u PASS: t-lorrshift1 PASS: t-matrix22 /bin/bash: line 1: 13011 Aborted $tst t-mp_bases.log-t 21 FAIL: t-mp_bases PASS: t-mullow_basecase PASS: t-mullowhigh PASS: t-mulmid PASS: t-mulmod_2expm1 PASS: t-mulmod_2expp1 PASS: t-neg PASS: t-perfsqr PASS: t-redc_1 PASS: t-sb_bdiv_q PASS: t-sb_bdiv_qr PASS: t-sb_div_q PASS: t-sb_div_qr PASS: t-sb_divappr_q PASS: t-scan PASS: t-subadd_n PASS: t-tdiv_q PASS: t-tdiv_qr PASS: st_fat PASS: st_instrument = 3 of 49 tests failed See tests/mpn/test-suite.log Please report to http://groups.google.co.uk/group/mpir-devel/ = == MPIR 2.7.0: tests/mpn/test-suite.log == 3 of 49 tests failed. .. contents:: :depth: 2 FAIL: t-inv_divappr_q_n (exit: 134) === failed: nn = 3084, dn = 1542, qn = 1542, rn = 2312 --- GCC 4.8.3, -march=bdver2 -mtune=bdver2 -O3 (all pass with -mno-xop): PASS: t-inv_div_q /bin/bash: line 1: 19233 Aborted $tst t-inv_div_qr.log-t 21 FAIL: t-inv_div_qr /bin/bash: line 1: 19264 Aborted $tst t-inv_div_qr_n.log-t 21 FAIL: t-inv_div_qr_n /bin/bash: line 1: 19295 Aborted $tst t-inv_divappr_q.log-t 21 FAIL: t-inv_divappr_q /bin/bash: line 1: 19326 Aborted $tst t-inv_divappr_q_n.log-t 21 FAIL: t-inv_divappr_q_n /bin/bash: line 1: 19357 Aborted $tst t-invert.log-t 21 FAIL: t-invert PASS: t-iord_u PASS: t-lorrshift1 PASS: t-matrix22 PASS: t-mp_bases PASS: t-mullow_basecase PASS: t-mullowhigh PASS: t-mulmid PASS: t-mulmod_2expm1 PASS: t-mulmod_2expp1 PASS: t-neg PASS: t-perfsqr PASS: t-redc_1 PASS: t-sb_bdiv_q PASS: t-sb_bdiv_qr PASS: t-sb_div_q PASS: t-sb_div_qr PASS: t-sb_divappr_q PASS: t-scan PASS: t-subadd_n PASS: t-tdiv_q PASS: t-tdiv_qr PASS: st_fat PASS: st_instrument = 5 of 49 tests failed See tests/mpn/test-suite.log Please report to http://groups.google.co.uk/group/mpir-devel/ = == MPIR 2.7.0: tests/mpn/test-suite.log == 5 of 49 tests failed. .. contents:: :depth: 2 FAIL: t-inv_div_qr (exit: 134) == failed: remainder does not match -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] MPIR-2.7.0-alpha7 available for testing
leif wrote: MPIR's test suite now exposes GCC's XOP-brokenness (I *think* that's new in alpha7, but probably already in alpha5 or 6). AFAICT, there's not a single GCC version (supporting bdver*) that /isn't/ in some way broken w.r.t. XOP instructions, but so far MPIR wasn't affected (and GMP still isn't). (Haven't checked yet whether just the test suite miscompiles, but I at least hope the library itself isn't affected.) Nope, unfortunately (also) the library gets miscompiled. When I build the library with XOP instructions enabled and the test suite without, I'm getting the same five test failures with GCC 4.8.3, one less (i.e., only two) with GCC 4.9.0. Note however that this happens only with '-O3', otherwise GCC hardly ever emits XOP instructions at all (in my experience at least). -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] MPIR 2.7.0-alpha6 available for testing
Bill Hart wrote: I have just uploaded mpir-2.7.0 alpha6. A few warnings you may want to fix: mpn/generic: divrem_hensel_rsh_qr_1.c:95:2: warning: no newline at end of file [-Wnewline-eof] mullow_basecase.c:55:10: warning: explicitly assigning a variable of type 'mp_size_t' (aka 'long') to itself [-Wself-assign] for (i = i; i n - xn i yn; i++) ~ ^ ~ divexact.c:115:8: warning: expression result unused [-Wunused-value] dp; ^~ ../../mpir-2.7.0-alpha6/fft/fft_mfa_trunc_sqrt2.c:71:1: warning: unused label 'start' [-Wunused-label] (goto start; in #if 0 block) In file included from ../../mpir-2.7.0-alpha6/mpz/mul_ui.c:25: ../../mpir-2.7.0-alpha6/mpz/mul_i.h:97:49: warning: comparison of unsigned expression 0 is always false [-Wtautological-compare] SIZ(prod) = ((sign_product 0) ^ (small_mult 0)) ? -size : size; ~~ ^ ~ (#ifdef OPERATION_mul_ui = #define MULTIPLICAND_UNSIGNED mpir_ui such that small_mult is of type mpir_ui) ../../mpir-2.7.0-alpha6/cxx/ismpf.cc:133:5: warning: unused label 'fail' [-Wunused-label] ../mpir-2.7.0-alpha6/memory.c:52:70: warning: format specifies type 'unsigned int' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat] fprintf (stderr, GNU MP: Cannot allocate memory (size=%u)\n, size); ~~ ^~~~ %zu ../mpir-2.7.0-alpha6/memory.c:104:90: warning: format specifies type 'unsigned int' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat] fprintf (stderr, GNU MP: Cannot reallocate memory (old_size=%u new_size=%u)\n, old_size, new_size); ~~ ^~~~ %zu ../mpir-2.7.0-alpha6/memory.c:104:100: warning: format specifies type 'unsigned int' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat] fprintf (stderr, GNU MP: Cannot reallocate memory (old_size=%u new_size=%u)\n, old_size, new_size); ~~^~~~ %zu ../../../mpir-2.7.0-alpha6/tests/fft/t-fft_ifft_mfa_trunc_sqrt2.c:62:25: warning: passing 'mp_size_t *' (aka 'long *') to parameter of type 'mp_ptr' (aka 'unsigned long *') converts between pointers to integer types with different sign [-Wpointer-sign] mpn_rrandom(trunc, state, 1); ^~ ../../mpir.h:1803:53: note: passing argument to parameter here __GMP_DECLSPEC void mpn_rrandom __GMP_PROTO ((mp_ptr, gmp_randstate_t, mp_size_t)); ../../../mpir-2.7.0-alpha6/tests/mpz/t-tdiv.c:40:15: warning: string literal of length 5673 exceeds maximum length 4095 that ISO C99 compilers are required to support [-Woverlength-strings] ../../../mpir-2.7.0-alpha6/tests/mpz/t-tdiv.c:56:15: warning: string literal of length 5172 exceeds maximum length 4095 that ISO C99 compilers are required to support [-Woverlength-strings] ../../../mpir-2.7.0-alpha6/tests/mpz/t-tdiv.c:57:15: warning: string literal of length 4372 exceeds maximum length 4095 that ISO C99 compilers are required to support [-Woverlength-strings] ../../../mpir-2.7.0-alpha6/tests/cxx/t-locale.cc:37:2: warning: extra ';' outside of a function is a C++11 extension [-Wc++11-extra-semi] With ABI=32, GCC 4.9 (at least) by default also gives a warning: ../../mpir-2.7.0-alpha6/mpz/inp_raw.c:80:5: warning: left shift count = width of type csize |= (mp_size_t)(-1) 32; ^ /* Sign extend if necessary. Could write csize -= ((csize 0x8000L) 1), but that tickles a bug in gcc 3.0 for powerpc64 on AIX. */ /* We exculde win32 as msvc gives a spurious warning */ #if !defined(_WIN32) || defined(_WIN64) if (sizeof (csize) 4 csize 0x8000L) csize |= (mp_size_t)(-1) 32; #endif (Only three or four are a bit annoying IMHO, besides the -Wformat ones.) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] mpirxx.h file missing, Visual Studio2013
Guillermo Ramírez wrote:
Hello Brian,
However, many people do run into problems when they build x64
applications on Windows becasue they wrongly assume that long types have
64-bits when in fact these types have 32-bits on Windows. To obtain a
64-bit type 'long long' has to be used.
MPIR itself has two predefined (signed and unsigned) integer types -
mpir_si and mpir_ui - that avoid this problem by being defined as 32-bit
types on win32 and 64-bit types on x64. If these are used in building
applications, it is often be possible to avoid many (but not all) of the
issues that turn up in porting win32 applications to x64.
Does the above mean that the user needs to change the mpirxx.h file to a
specific
arithmetic type?
No.
I am trying to use the open source libDAI library and am having several
errors and
warnings with the mpirxx.h file, for instance:
Error1error C4146: unary minus operator applied to unsigned type, result
still unsigned
C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\include\mpirxx.h1181GBP1
Line 118 really looks a bit weird; the minus should IMHO precede 'l':
inline void __mpz_set_si_safe(mpz_ptr p, mpir_si l)
{
if(l 0)
{
__mpz_set_ui_safe(p, -static_castmpir_ui(l)); // line 118
mpz_neg(p, p);
}
else
__mpz_set_ui_safe(p, l);
// Note: we know the high bit of l is 0 so we could do slightly better
}
Warning18warning C4244: 'argument' : conversion from '__int64' to
'mpir_si', possible loss of data
C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\include\mpirxx.h15431GBP1
Here my impression is that mpir_si is indeed defined to (just) 32 bits
(= win32), otherwise the warning doesn't make sense:
#ifdef MPIRXX_HAVE_LLONG
__gmp_expr(signed long long int l) { mpz_init_set_si(mp, l); } //
line 1543
__gmp_expr(unsigned long long int l) { mpz_init_set_ui(mp, l); }
#endif
On the other hand, there should be a warning for the next line as well
(assuming mpir_ui is also just 32 bits).
Probably MPIRXX_HAVE_LLONG shouldn't be defined in that case? (The
logic w.r.t. to that preprocessor variable is at least a bit confusing
IIRC.)
Brian will know better, as he has tested on (and maintains the) Windows
(version)...
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] mpirxx.h file missing, Visual Studio2013
Brian Gladman wrote: On 30/05/2014 22:56, Marc wrote: Le vendredi 30 mai 2014 23:21:49 UTC+2, Cactus a écrit : If you are suggesting that the line: __mpz_set_ui_safe(p, -static_castmpir_ui(l)); would be better expressed as: __mpz_set_ui_safe(p, static_castmpir_ui(-l)); I can only agree with you and plead guilty for introducing this weirdness. Please look at the history before making such changes. There is a reason why I wrote it this way, computing -LONG_MIN is undefined behavior while the corresponding unsigned operation is perfectly well defined, whatever the silly warning says. I did wonder about this edge case but I was not aware that C/C++ explicitly specifies taking the negative of the signed value 0x8000 as undefined behaviour. I wonder how many compilers (or architectures) don't give 0x8000... as the result of this operation? I rather wonder what the M$ compilers do / make of it in both cases... ;-) (FWIW, GCC gives a warning when explicitly taking -(LONG_MIN), while clang 3.4.1 doesn't, even with -Wall -pedantic.) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] mpz_get_d() with rounding
Jeroen Demeyer wrote:
The function mpz_get_d() rounds towards zero. This is incompatible with
the usual floating-point semantics of rounding to nearest. In C on my
machine for example, a conversion from unsigned long to double rounds to
nearest. Would you agree with adding additional functions (or one
function with an MPFR-style rounding flag) for other rounding modes?
Did you post to gmp-{devel,discuss} as well?
(I'm not subscribed to these lists, but couldn't see a post of you in
the list archives either; the latter ends in April.)
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] mpz_set_str bug?
Bill Hart wrote: On 14 May 2014 06:30, Loi Luu loi.luu...@gmail.com mailto:loi.luu...@gmail.com wrote: Please read my reply below. Thanks, Loi Luu. On Wed, May 14, 2014 at 6:17 AM, Bill Hart goodwillh...@googlemail.com mailto:goodwillh...@googlemail.com wrote: On 14 May 2014 00:00, Loi Luu loi.luu...@gmail.com mailto:loi.luu...@gmail.com wrote: So I guess that the strings in the argument are actually numbers in base 62, thats why all leading 0s are eliminated. Well, they aren't eliminated as such. Which number would you say 0123 represented in decimal notation? I would say it represents the number 123. So my point is that, the parameters here are actual numbers, not normal strings. No, 0123 is a normal C string. Hence 0123 in decimal base equals to 123. Yes, it does: 0 x 1000 + 1 x 100 + 2 x 10 + 3 = 1 x 100 + 2 x 10 + 3. I thought that the parameter (for example in base 10) could be normal strings consisting only digit characters they are , and the mpz_set_str will return different value for different string. It depends on the strings. Which different values would expect 0123 and 123 return? We already established these are two string representations of the same number. So if you pass these strings to mpz_set_str, it should return the same number, yes? There are lots of representations of the same number: one hundred and twenty three, 123, 0123, 00123, 123.0, 123.00, 1.23e2, etc. Well, in C 0123 == 83 ... ;-) -leif In this case, the function mpz_set_str will take the strings 0123 and 123 in base 10 and return the same number, because in base 10, they are representations of the same number. Of course, just to make things slightly more confusing, an mpz_t also has an internal representation for numbers, which as I mentioned, is base 2^32 or 2^64 (each digit is represented as a string of binary digits, i.e. base 2). When you print an mpz_t, unless you tell it to do otherwise, it will again convert the number to a base 10 string. So: stringmpz_tstring 0123 - 011 - 123 (on a 32 bit machine) The mpz_set_str step is the first one. Note that the mpz_t consists of one 32 bit digit, represented with 32 binary bits. When printing the mpz_t (say with gmp_printf(%Zd), it chooses the most commonly used representation, which is base 10 with no leading zeroes). Hope this helps. Bill. I was thinking that mpz_set_str would act like an encoding function which convert a string in domain of base characters to mpz_t element. I don't know what an encoding function is, sorry. Bill. Thanks, On 14 May 2014 05:53, Bill Hart goodwillh...@googlemail.com mailto:goodwillh...@googlemail.com wrote: Why? What different value are you expecting it to set it to? Bill. On 13 May 2014 21:16, Loi Luu loi.luu...@gmail.com mailto:loi.luu...@gmail.com wrote: Hi Bill, Wouldn't mpz_set_str(0abc, 62) differ from mpz_set_str(abc, 62)? Thanks, On Tuesday, May 13, 2014 11:22:35 PM UTC+8, Bill Hart wrote: I don't understand what you mean. What values were you hoping for? For example, in base 10, I would hope the strings 0123 and 123 both gave the value 123. After all, the internal representation of an mpz_t is base 2^64 (or 2^32). It doesn't know anything about base 10 or 62. Bill. On 13 May 2014 16:56, Loi Luu loi.l...@gmail.com wrote: Hi, I use mpz_set_str to convert a string to mpz_t with base 62. However, that function eliminates all leading 0 in the string and gives the results of 0S and S as the same (for any non-0 leading string S). I wonder whether its a bug of mpz_set_str or its there in the description of the function. Thanks, -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options
Re: [mpir-devel] make a string from mpz_t x
David edwards jr wrote: thank you leif. works well and with the protection not in sprintf. I also found it in the pdf file that I had. I simply did not go down to the functions section Note that while gmp_snprintf() protects your buffer from overflowing, it doesn't protect you from truncated numbers. If the buffer was too small, [gmp_]snprintf() returns a number = the size you passed to it. You can use mpz_sizeinbase(x, 10) to check in advance whether your number x will fit into the string buffer (in decimal notation, i.e., base 10). Your buffer should be at least two bytes larger than that (assuming you use just %Zd); one byte for a possible '-' sign, one for the trailing '\0'. See also mpz_get_str(), which does the necessary allocation for you if you pass NULL instead of the address of a buffer; it's up to you to free the allocated memory afterwards when necessary or appropriate though. -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] gmp_randseed crashes after gmp_randinit_set for a mersenne twister random number generator
Brian Gladman wrote: On 30/04/2014 17:32, Alex Dyachenko wrote: On Wednesday, April 30, 2014 11:59:36 AM UTC-4, Cactus wrote: There is no sense in initialising after such a call since you get exactly the same effect by calling gmp_randinit_mt(b). However, we could (and maybe should) avoid the crash by allowing the user to reseed in this way even though doing this is not really sensible (this amounts to defensive programming on our part). This was part of a larger test where I was reseeding back to the same value multiple times in order to restart the sequence. I give you that it's a contrived scenario, but a unit test is exactly where it might feasibly occur. It's cool if this is deemed by design, as long as it's documented that you can't seed after copying. Also, the int return of gmp_randinit_set is not documented. Yes, its either a bug or a feature that should be dodcumented. But even if we document it, I would like to see an error return rather than a crash if we want to make such re-seeding illegal. With __attribute__ ((__warn_unused_result__)) ? Otherwise I'd rather call abort(). -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Error building PPL on Cygwin64
Jean-Pierre Flori wrote: FYI, same failure on gcc110 (linux/POWER7). g++ -v? The current logic in mpirxx.h is IMHO really pretty fragile. Note btw. that C99 long longs aren't part of C++98, hence a preprocessor for the latter (including '-std=c++98') doesn't even have to support them (i.e., LL/ULL literals). Besides giving some macros more intuitive names, I'd first make sure every used macro is indeed defined (and error out or give a warning otherwise). (MPIR_HAVE_STDINT for example doesn't imply that it has been included, nor that the relevant macros are defined [in C++].) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Error building PPL on Cygwin64
Brian Gladman wrote: On 08/04/2014 00:14, Bill Hart wrote: On Cygwin64 intmax_t should be long long. Anyway, we can compile those guards and see which is evaluating incorrectly. Possibly some header defining LLONG_MAX is missing, or something like that. On Cygwin64 it seems that longs are 8 bytes. So we have an supposed Windows ABI that has not adopted the Windows ABI! I guess ridding the earth of Windows is not one of the possible solutions open to us? -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] MPIR-2.7.0-alpha1, testing needed
leif wrote: Ok, here's minimalist's quick'n'dirty temporary solution; minimally-invasive in that it touches only one file and affects only Darwin x86_64 :-) : --- mpir-2.7.0-alpha2/configure.ac +++ mpir-2.7.0-alpha2/configure.ac @@ -2843,15 +2843,18 @@ ;; 64) + GMP_INCLUDE_MPN(x86_64/x86_64-defs.m4) case $host in *-*-darwin*) + # Defined in mpn/x86_64/x86_64-defs.m4, but there currently + # hardcoded just for ELF, so redefine it here for Mach-O: + GMP_DEFINE_RAW([define(\`JUMPTABSECT',RODATA)],POST) OBJECT_FORMAT=-f macho64 ;; *-w64-mingw*|*-*-cygwin*) OBJECT_FORMAT=-f x64 ;; *) OBJECT_FORMAT=-f elf64 ;; esac - GMP_INCLUDE_MPN(x86_64/x86_64-defs.m4) ;; esac AC_SUBST(OBJECT_FORMAT) Patched tarball (of course also including a re-autoconfed 'configure') for the Apple fanboys to test is available here: http://boxen.math.washington.edu/home/leif/tmp/mpir-2.7.0-alpha2-patched_for_darwin-x86_64.tar.bz2 Update, please try this one: http://boxen.math.washington.edu/home/leif/tmp/mpir-2.7.0-alpha3-patched_for_darwin-x86_64.tar.bz2 (extracts to mpir-2.7.0-alpha3-patched/ ) -leif Happy testing, we want to include it into Sage soon I think, -leif P.S.: Haven't looked at Darwin PPC at all, but in case there should be any issues, they'll be different... :-) -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] MPIR-2.7.0-alpha1, testing needed
Bill Hart wrote: Can you tell me what the changes are so I can merge them? diff -Naur mpir-2.7.0-alpha3/configure mpir-2.7.0-alpha3-patched/configure --- mpir-2.7.0-alpha3/configure +++ mpir-2.7.0-alpha3-patched/configure @@ -25408,7 +25408,7 @@ # Defined in mpn/x86_64/x86_64-defs.m4, but there currently # hardcoded just for ELF, so redefine it here for Mach-O: -echo define(\`JUMPTABSECT',RODATA) $gmp_tmpconfigm4p +echo define(\`JUMPTABSECT',\` .section __DATA,__const') $gmp_tmpconfigm4p OBJECT_FORMAT=-f macho64 ;; *-w64-mingw*|*-*-cygwin*) diff -Naur mpir-2.7.0-alpha3/configure.ac mpir-2.7.0-alpha3-patched/configure.ac --- mpir-2.7.0-alpha3/configure.ac +++ mpir-2.7.0-alpha3-patched/configure.ac @@ -2847,7 +2847,7 @@ *-*-darwin*) # Defined in mpn/x86_64/x86_64-defs.m4, but there currently # hardcoded just for ELF, so redefine it here for Mach-O: - GMP_DEFINE_RAW([define(\`JUMPTABSECT',RODATA)],POST) + GMP_DEFINE_RAW([define(\`JUMPTABSECT',\` .section __DATA,__const')],POST) OBJECT_FORMAT=-f macho64 ;; *-w64-mingw*|*-*-cygwin*) OBJECT_FORMAT=-f x64 ;; -leif On 6 April 2014 18:03, leif not.rea...@online.de mailto:not.rea...@online.de wrote: leif wrote: Ok, here's minimalist's quick'n'dirty temporary solution; minimally-invasive in that it touches only one file and affects only Darwin x86_64 :-) : --- mpir-2.7.0-alpha2/configure.ac http://configure.ac +++ mpir-2.7.0-alpha2/configure.ac http://configure.ac @@ -2843,15 +2843,18 @@ ;; 64) + GMP_INCLUDE_MPN(x86_64/x86_64-__defs.m4) case $host in *-*-darwin*) + # Defined in mpn/x86_64/x86_64-defs.m4, but there currently + # hardcoded just for ELF, so redefine it here for Mach-O: + GMP_DEFINE_RAW([define(\`__JUMPTABSECT',RODATA)],POST) OBJECT_FORMAT=-f macho64 ;; *-w64-mingw*|*-*-cygwin*) OBJECT_FORMAT=-f x64 ;; *) OBJECT_FORMAT=-f elf64 ;; esac - GMP_INCLUDE_MPN(x86_64/x86_64-__defs.m4) ;; esac AC_SUBST(OBJECT_FORMAT) Patched tarball (of course also including a re-autoconfed 'configure') for the Apple fanboys to test is available here: http://boxen.math.washington.__edu/home/leif/tmp/mpir-2.7.0-__alpha2-patched_for_darwin-x86___64.tar.bz2 http://boxen.math.washington.edu/home/leif/tmp/mpir-2.7.0-alpha2-patched_for_darwin-x86_64.tar.bz2 Update, please try this one: http://boxen.math.washington.__edu/home/leif/tmp/mpir-2.7.0-__alpha3-patched_for_darwin-x86___64.tar.bz2 http://boxen.math.washington.edu/home/leif/tmp/mpir-2.7.0-alpha3-patched_for_darwin-x86_64.tar.bz2 (extracts to mpir-2.7.0-alpha3-patched/ ) -leif Happy testing, we want to include it into Sage soon I think, -leif P.S.: Haven't looked at Darwin PPC at all, but in case there should be any issues, they'll be different... :-) -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Re: MPIR-2.7.0-alpha1, testing needed
On 05.04.2014 13:40, Bill Hart wrote: Linux/unix: wget http://mpir.org/mpir-2.7.0-alpha2.tar.bz2 http://mpir.org/mpir-2.7.0-alpha1.tar.bz2 tar -xvf mpir-2.7.0-alpha1.tar.bz2 cd mpir-2.7.0 ./configure --enable-gmpcompat --enable-cxx make make check Configuring with '--build=prescott-pc-linux-gnu' now also works (correct ABI, MPN_PATH, C- and CXXFLAGS). -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] MPIR-2.7.0-alpha1, testing needed
On 05.04.2014 02:55, Bill Hart wrote: Hi all, I have put tarballs up on our website (http://mpir.org) for MPIR-2.7.0-alpha1. As this release contains rather a lot of new code and speedups, we'd like to have it tested as widely as possible. We welcome build/test reports (positive and negative) either here or on our mpir-devel Google Group. MacOS X 10.6.8 (Darwin 10), Apple GCC 4.2.1, x86_64: /bin/sh ../libtool --mode=compile --tag=CC ../../mpir-2.7.0-alpha2/mpn/m4-ccas --m4=m4 gcc -std=gnu99 -c -DHAVE_CONFIG_H-m64 -O2 -march=core2 -mtune=core2 -D__GMP_WITHIN_GMP -I../../mpir-2.7.0-alpha2 -DOPERATION_`echo sqr_basecase | sed 's/_$//'` -I. -I../../mpir-2.7.0-alpha2/mpn -I.. `test -f 'sqr_basecase.asm' || echo '../../mpir-2.7.0-alpha2/mpn/'`sqr_basecase.asm libtool: compile: ../../mpir-2.7.0-alpha2/mpn/m4-ccas --m4=m4 gcc -std=gnu99 -c -DHAVE_CONFIG_H -m64 -O2 -march=core2 -mtune=core2 -D__GMP_WITHIN_GMP -I../../mpir-2.7.0-alpha2 -DOPERATION_sqr_basecase -I. -I../../mpir-2.7.0-alpha2/mpn -I.. sqr_basecase.asm -fno-common -DPIC -o .libs/sqr_basecase.o m4 -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_sqr_basecase -DPIC sqr_basecase.asm tmp-sqr_basecase.s gcc -std=gnu99 -c -DHAVE_CONFIG_H -m64 -O2 -march=core2 -mtune=core2 -D__GMP_WITHIN_GMP -I../../mpir-2.7.0-alpha2 -DOPERATION_sqr_basecase -I. -I../../mpir-2.7.0-alpha2/mpn -I.. tmp-sqr_basecase.s -fno-common -DPIC -o .libs/sqr_basecase.o tmp-sqr_basecase.s:136:segment-name: .data.rel.ro.local too long (maximum 16 characters) tmp-sqr_basecase.s:136:Rest of line ignored. 1st junk character valued 64 (@). make[2]: *** [sqr_basecase.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 $ as -v Apple Inc version cctools-795~45, GNU assembler version 1.38 $ ../mpir-2.7.0-alpha2/config.guess westmere-apple-darwin10.8.0 $ grep -A6 '^using' configure.1.log using ABI=64 CC=gcc -std=gnu99 CFLAGS=-m64 -O2 -march=core2 -mtune=core2 CPPFLAGS= CXX=g++ CXXFLAGS=-m64 -O2 -march=core2 -mtune=core2 MPN_PATH= x86_64/nehalem/westmere x86_64/nehalem x86_64 generic (This is bsd.math at UW; [vanilla] MPIR 2.6.0 passed 'make check' (without --enable-cxx) with this configuration.) -leif P.S.: I think this one during yasm's 'configure' is rather harmless: ... checking for _stricmp... no checking for strcmpi... no checking whether NLS is requested... yes checking for msgfmt... no checking for gmsgfmt... : checking for xgettext... ../../mpir-2.7.0-alpha2/yasm/configure: line 5907: 18685 Trace/BPT trap $ac_dir/$ac_word --omit-header --copyright-holder= --msgid-bugs-address= /dev/null 15 21 no checking for msgmerge... no checking build system type... x86_64-apple-darwin10.8.0 checking host system type... x86_64-apple-darwin10.8.0 checking for ld used by GCC... /usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld ... -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] MPIR-2.7.0-alpha1, testing needed
Bill Hart wrote: I don't know how to fix that. The line in question is: .section .data.rel.ro.local,aw,@progbits Ahem, that's an *ELF* section name (along with its attributes)... It is complaining that .data.rel.ro.local is too long. Yeah, we're on Darwin, and Mach-O section names are limited to 16 characters. The section name declaration comes from JUMPTABSECT, which is hardcoded (btw. twice; same for JMPENT) into mpn/x86_64/x86_64-defs.m4; and unfortunately there's no macho.m4 / darwin.m4 or elf.m4 at all in that folder. If I --- config.m4.orig 2014-04-05 17:06:55.0 -0700 +++ config.m4 2014-04-05 17:07:49.0 -0700 @@ -28,6 +28,7 @@ ifdef(`__CONFIG_M4_INCLUDED__',,` include(CONFIG_TOP_SRCDIR`/mpn/asm-defs.m4') include_mpn(`x86_64/x86_64-defs.m4') +define(`JUMPTABSECT',RODATA) define_not_for_expansion(`HAVE_ABI_64') define_not_for_expansion(`HAVE_LIMB_LITTLE_ENDIAN') define_not_for_expansion(`HAVE_DOUBLE_IEEE_LITTLE_ENDIAN') 'make' succeeds and all tests pass (with both Apple's GCC 4.2.1 as well as FSF's GCC 4.7.3). (RODATA gets defined by 'configure', and here expands to '.text'.) So you'd have to weave that into 'configure', either by [re]defining JUMPTABSECT (on Darwin x86_64) directly there, or defining some macro telling m4 that we're on Darwin, and ifdef'ing in x86_64-defs.m4 (also removing the redundant second definition ;-) ). Or let 'configure' include some mpn/x86_64/darwin.m4 (optionally also some elf.m4 on ELF systems), and properly define the platform-dependent macros there. (Or just define DARWIN in darwin.m4, again letting 'configure' include it, and special-case on that macro in the generic x86_64-defs.m4.) Sorry, I'm not going to mess with autotools right now. It's usually already an adventure to find out which versions of autoconf, automake and libtool an upstream project currently uses, and to flawlessly bring them into place, in order to minimize the patches to their generated files. Unfortunately .data.rel.ro.local is part of the assembler/linker syntax to prevent certain kinds of memory corruption. It seems when they came up with this syntax, they forgot to check that it was actually supported by past versions of their assembler! It probably should be reported as a bug to the binutils people, since it is going to stop a lot of code compiling on Macs. The linker hint should have been chosen with a shorter name. Well, if at all, to Apple... B) -leif On 5 April 2014 23:14, leif not.rea...@online.de mailto:not.rea...@online.de wrote: On 05.04.2014 02:55, Bill Hart wrote: Hi all, I have put tarballs up on our website (http://mpir.org) for MPIR-2.7.0-alpha1. As this release contains rather a lot of new code and speedups, we'd like to have it tested as widely as possible. We welcome build/test reports (positive and negative) either here or on our mpir-devel Google Group. MacOS X 10.6.8 (Darwin 10), Apple GCC 4.2.1, x86_64: /bin/sh ../libtool --mode=compile --tag=CC ../../mpir-2.7.0-alpha2/mpn/__m4-ccas --m4=m4 gcc -std=gnu99 -c -DHAVE_CONFIG_H-m64 -O2 -march=core2 -mtune=core2 -D__GMP_WITHIN_GMP -I../../mpir-2.7.0-alpha2 -DOPERATION_`echo sqr_basecase | sed 's/_$//'` -I. -I../../mpir-2.7.0-alpha2/mpn -I.. `test -f 'sqr_basecase.asm' || echo '../../mpir-2.7.0-alpha2/mpn/'__`sqr_basecase.asm libtool: compile: ../../mpir-2.7.0-alpha2/mpn/__m4-ccas --m4=m4 gcc -std=gnu99 -c -DHAVE_CONFIG_H -m64 -O2 -march=core2 -mtune=core2 -D__GMP_WITHIN_GMP -I../../mpir-2.7.0-alpha2 -DOPERATION_sqr_basecase -I. -I../../mpir-2.7.0-alpha2/mpn -I.. sqr_basecase.asm -fno-common -DPIC -o .libs/sqr_basecase.o m4 -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_sqr_basecase -DPIC sqr_basecase.asm tmp-sqr_basecase.s gcc -std=gnu99 -c -DHAVE_CONFIG_H -m64 -O2 -march=core2 -mtune=core2 -D__GMP_WITHIN_GMP -I../../mpir-2.7.0-alpha2 -DOPERATION_sqr_basecase -I. -I../../mpir-2.7.0-alpha2/mpn -I.. tmp-sqr_basecase.s -fno-common -DPIC -o .libs/sqr_basecase.o tmp-sqr_basecase.s:136:__segment-name: .data.rel.ro.local too long (maximum 16 characters) tmp-sqr_basecase.s:136:Rest of line ignored. 1st junk character valued 64 (@). make[2]: *** [sqr_basecase.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 $ as -v Apple Inc version cctools-795~45, GNU assembler version 1.38 $ ../mpir-2.7.0-alpha2/config.__guess westmere-apple-darwin10.8.0 $ grep -A6 '^using' configure.1.log using ABI=64 CC=gcc -std=gnu99 CFLAGS=-m64 -O2 -march=core2 -mtune=core2 CPPFLAGS= CXX=g++ CXXFLAGS=-m64 -O2 -march=core2 -mtune=core2 MPN_PATH= x86_64/nehalem/westmere x86_64/nehalem x86_64 generic (This is bsd.math at UW; [vanilla] MPIR 2.6.0 passed 'make check
Re: [mpir-devel] MPIR-2.7.0-alpha1, testing needed
leif wrote: leif wrote: Bill Hart wrote: I don't know how to fix that. The line in question is: .section .data.rel.ro.local,aw,@progbits Ahem, that's an *ELF* section name (along with its attributes)... It is complaining that .data.rel.ro.local is too long. Yeah, we're on Darwin, and Mach-O section names are limited to 16 characters. The section name declaration comes from JUMPTABSECT, which is hardcoded (btw. twice; same for JMPENT) into mpn/x86_64/x86_64-defs.m4; and unfortunately there's no macho.m4 / darwin.m4 or elf.m4 at all in that folder. If I --- config.m4.orig2014-04-05 17:06:55.0 -0700 +++ config.m42014-04-05 17:07:49.0 -0700 @@ -28,6 +28,7 @@ ifdef(`__CONFIG_M4_INCLUDED__',,` include(CONFIG_TOP_SRCDIR`/mpn/asm-defs.m4') include_mpn(`x86_64/x86_64-defs.m4') +define(`JUMPTABSECT',RODATA) define_not_for_expansion(`HAVE_ABI_64') define_not_for_expansion(`HAVE_LIMB_LITTLE_ENDIAN') define_not_for_expansion(`HAVE_DOUBLE_IEEE_LITTLE_ENDIAN') 'make' succeeds and all tests pass (with both Apple's GCC 4.2.1 as well as FSF's GCC 4.7.3). (RODATA gets defined by 'configure', and here expands to '.text'.) So you'd have to weave that into 'configure', either by [re]defining JUMPTABSECT (on Darwin x86_64) directly there, or defining some macro telling m4 that we're on Darwin, and ifdef'ing in x86_64-defs.m4 (also removing the redundant second definition ;-) ). Or let 'configure' include some mpn/x86_64/darwin.m4 (optionally also some elf.m4 on ELF systems), and properly define the platform-dependent macros there. (Or just define DARWIN in darwin.m4, again letting 'configure' include it, and special-case on that macro in the generic x86_64-defs.m4.) I think a macro definition or macro file inclusion would perfectly fit here (configure.ac lines 2826--2858, relevant is only the ABI=64 branch): X86_PATTERN | X86_64_PATTERN) GMP_ASM_ALIGN_FILL_0x90 case $ABI in 32) GMP_INCLUDE_MPN(x86/x86-defs.m4) GMP_ASM_COFF_TYPE GMP_ASM_X86_GOT_UNDERSCORE GMP_ASM_X86_SHLDL_CL case $enable_profiling in prof | gprof) GMP_ASM_X86_MCOUNT ;; esac case $host in *-*-darwin*) OBJECT_FORMAT=-f macho32 ;; *) OBJECT_FORMAT=-f elf32 ;; esac ;; 64) case $host in *-*-darwin*) OBJECT_FORMAT=-f macho64 ;; *-w64-mingw*|*-*-cygwin*) OBJECT_FORMAT=-f x64 ;; *) OBJECT_FORMAT=-f elf64 ;; esac GMP_INCLUDE_MPN(x86_64/x86_64-defs.m4) ;; esac AC_SUBST(OBJECT_FORMAT) ;; I'd move GMP_INCLUDE_MPN(x86_64/x86_64-defs.m4) a few lines up, right before the 'case', and add a GMP_DEFINE() to the *-*-darwin* branch (either defining just DARWIN, or redefining JUMPTABSECT there). Ok, here's minimalist's quick'n'dirty temporary solution; minimally-invasive in that it touches only one file and affects only Darwin x86_64 :-) : --- mpir-2.7.0-alpha2/configure.ac +++ mpir-2.7.0-alpha2/configure.ac @@ -2843,15 +2843,18 @@ ;; 64) + GMP_INCLUDE_MPN(x86_64/x86_64-defs.m4) case $host in *-*-darwin*) + # Defined in mpn/x86_64/x86_64-defs.m4, but there currently + # hardcoded just for ELF, so redefine it here for Mach-O: + GMP_DEFINE_RAW([define(\`JUMPTABSECT',RODATA)],POST) OBJECT_FORMAT=-f macho64 ;; *-w64-mingw*|*-*-cygwin*) OBJECT_FORMAT=-f x64 ;; *) OBJECT_FORMAT=-f elf64 ;; esac - GMP_INCLUDE_MPN(x86_64/x86_64-defs.m4) ;; esac AC_SUBST(OBJECT_FORMAT) Patched tarball (of course also including a re-autoconfed 'configure') for the Apple fanboys to test is available here: http://boxen.math.washington.edu/home/leif/tmp/mpir-2.7.0-alpha2-patched_for_darwin-x86_64.tar.bz2 Happy testing, we want to include it into Sage soon I think, -leif P.S.: Haven't looked at Darwin PPC at all, but in case there should be any issues, they'll be different... :-) Or, leave GMP_INCLUDE_MPN(x86_64/x86_64-defs.m4) where it is, and add GMP_INCLUDE_MPN(x86_64/darwin.m4) and optionally also GMP_INCLUDE_MPN(x86_64/elf.m4) to the corresponding branches, then either just defining DARWIN and ELF in those files to special-case on them in x86_64-defs.m4, or defining the platform-specific macros (like JUMPTABSECT) directly there. (The problem with the latter is that some platform-specific macros are directly [determined and] defined by 'configure', although they'd probably better fit into such an OBJECTFILEFORMAT.m4.) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed
Re: [mpir-devel] Re: Progress towards the release
Brian Gladman wrote: On 02/04/2014 19:57, Bill Hart wrote: I have recently made quite a few changes to format specifiers in test code, so I hope this is all still ok on Windows. If not, please let me know. I didn't fix this problem permanently, which I think will involve adding some new format specifiers to gmp_printf and using it instead of printf, since MSVC doesn't support the c99 format specifiers. But this can wait until the next release. Or perhaps there is a way to make recent MSVC accept C99 format specifiers for uintmax_t, intmax_t and size_t and a workaround for %ld vs %lld. As of Visual Studio 2013 it does :-) VS 2013 has gone a long way towaards C99 and C++ 11. See the links below if you are interested in the details: http://msdn.microsoft.com/en-us/library/hh409293.aspx http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx http://msdn.microsoft.com/en-us/library/hh567368.aspx Of course this is not much help if we want to continue support for previous versions :-( Why don't you just use the macros (PRI...) from inttypes.h, and, depending on HAVE_INTTYPES_H and/or the MSVC version, define the few you need yourself? (Or did I miss something?) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Re: Progress towards the release
Brian Gladman wrote: On 02/04/2014 22:49, leif wrote: Brian Gladman wrote: On 02/04/2014 19:57, Bill Hart wrote: I have recently made quite a few changes to format specifiers in test code, so I hope this is all still ok on Windows. If not, please let me know. I didn't fix this problem permanently, which I think will involve adding some new format specifiers to gmp_printf and using it instead of printf, since MSVC doesn't support the c99 format specifiers. But this can wait until the next release. Or perhaps there is a way to make recent MSVC accept C99 format specifiers for uintmax_t, intmax_t and size_t and a workaround for %ld vs %lld. As of Visual Studio 2013 it does :-) VS 2013 has gone a long way towaards C99 and C++ 11. See the links below if you are interested in the details: http://msdn.microsoft.com/en-us/library/hh409293.aspx http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx http://msdn.microsoft.com/en-us/library/hh567368.aspx Of course this is not much help if we want to continue support for previous versions :-( Why don't you just use the macros (PRI...) from inttypes.h, and, depending on HAVE_INTTYPES_H and/or the MSVC version, define the few you need yourself? (Or did I miss something?) No, you didn't! My problem is that (a) the issue is only about 24 hours old (Bill raised it, I think, yesterday), (b) inttypes.h is completely new to me as it has only been available in Visual Studio for a few months, and (c) until Bill raised it, I didn't even know that I should take any interest in it! Well, their use looks pretty ugly, or is a bit tedious to type (IMHO); instead of e.g. #if ... /* long long is 64 bits, long is only 32 bits */ printf(%lld\n, bigval); #else /* long is already 64 bits */ printf(%ld\n, bigval); #endif you'd write printf(%PRId64\n, bigval); I.e., PRId64 expands just to a string containing the appropriate format specifier (not including the percent sign, such that one can also write things like %20PRId64 etc.). But you'd only have to modify the test code I think. But if Bill wants to use inttypes.h, we can certainly use it in VS 2013 and do what you suggest for earlier versions. There are also earlier non-Microsoft versions of this header that we could use on these versions. On *nix, 'configure' already checks for inttypes.h (and config.h defines HAVE_INTTYPES_H accordingly). -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Dropping Windows support (phew!!)
On 01.04.2014 01:29, Bill Hart wrote: Hi all, By now everyone will have heard about Canonical's new product, called Youbetcha, which claims to offer native support for Linux applications in Windows *at native speed*. Hmmm, I was expecting it to run applications *twice* as fast as on native Linux. But it's not yet available in the U.S. anyway. -leif I wish this had come along earlier, since even yesterday (Monday), I was spitting chips at the 45 minutes it takes just to run autotools configure in MinGW, MinGW64, Cygwin or Cygwin64. Well, I've just tried out Youbetcha (see http://www.ubuntu.com/) and it really works flawlessly! It took about 45 minutes to install, but now MPIR works out-of-the box on my HP laptop and builds in 30s on 4 cores instead of 1.5 hours using any of the above. Therefore, let me be the first to announce that MPIR and flint will be dropping support for Windows as of today (1/4). We recommend Windows users download Youbetcha for themselves and install it at the first opportunity. Bill. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Re: Progress towards the release
On 29.03.2014 12:48, Bill Hart wrote: All tests now pass on MinGW, MinGW64, Cygwin and Cygwin64. For the first time ever! Windows FTW! ;-) The fix for issue #23 is incomplete though; you apparently missed the patch to acinclude.m4: --- src/acinclude.m42013-02-27 04:51:08.528733998 +0100 +++ src/acinclude.m42013-02-27 06:19:10.558735026 +0100 @@ -41,7 +41,7 @@ [[powerpc64-*-* | powerpc64le-*-* | powerpc620-*-* | powerpc630-*-* | powerpc970-*-* | power[3-9]-*-*]]) define(X86_PATTERN, -[[i?86*-*-* | k[5-8]*-*-* | pentium*-*-* | athlon-*-* | viac3*-*-*]]) +[[i?86*-*-* | k[5-8]*-*-* | pentium*-*-* | prescott-*-* | core-*-* | athlon-*-* | viac3*-*-*]]) define(X86_64_PATTERN, [[x86_64-*-* | netburst-*-* | netburstlahf-*-* | k8-*-* | k10-*-* | k102-*-* | k103-*-* | core2-*-* | penryn-*-* | nehalem-*-* | westmere-*-* | sandybridge-*-* | atom-*-* | nano-*-* | bobcat-*-* | bulldozer-*-*]]) such that one still ends up with ABI=standard, an (almost) empty MPN_PATH (just containing generic) and incorrect / incomplete C- and CXXFLAGS. I have to admit I'm not sure whether I submitted the patches to the autotools *source* files upstream last year; they're contained in the Sage package (or nowadays the package metadata(?) for MPIR) though. -leif P.S.: In the long run, it may make sense to also have core-*-* and prescott-*-* have their own gmp-mparam.h files (by adding some subdirectories like you did for e.g. piledriver and bulldozer, and prepending them to their MPN_PATH, although there's not yet specific assembly code for these). My Prescott still doesn't get detected as such (just as an ordinary Pentium 4), because cpuid.c considers every model =6 of family 15 a plain Pentium 4, although model 3 and model 4 are (or at least can be?) Prescotts as well. (Mine is a model 3.) But that's a different story... On 20 March 2014 00:44, Bill Hart goodwillh...@googlemail.com mailto:goodwillh...@googlemail.com wrote: Today I finally fixed mpn_mulmod_2expp1 to use the FFT wraparound trick in the FFT region. As mpn_mulmod_bnm1 uses this function, this means that GMP-ECM will now be able to use MPIR more efficiently. I think that much of our mulmod_2expp1 and mulmod_bnm1 code needs rewriting, but this can wait until someone can do it properly. I also added some tuning for the new division functions. I'm not convinced it is picking the right thresholds, based on my own timings. But it's coded correctly, so there's nothing I can do about it. At least the division code doesn't seem to slow down with the new tuning values. Tomorrow I will add some tuning functions for the new GMP combinatorics functions that we added. I will also fix a bug in the fft tuning code which causes it to crash on some systems. This should hopefully complete all the new features for MPIR 2.7 and we can move on to closing all the open tickets for the release. I have essentially until the end of next week to do as much as I can, after which I will have to work weekends if it isn't done. After tomorrow we will need to retune MPIR on as many platforms as we can. Help with that would be appreciated. By the way, after May 31st we'll lose access to about half the machines we build on, due to one of the build farms closing down. So if anyone has access to lots of heterogeneous hardware with linux, git and recent gcc on it, please let us know. Bill. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Re: Progress towards the release
On 24.03.2014 17:17, Bill Hart wrote: I have now assigned 36 open tickets to the 2.7 release. I'm sure more will be added, but at least we now have some measure of how far we are from a release. Just in case that's not yet on the todo list: While --enable-cxx (and 'make check' with that) meanwhile works, apparently the checks for the C++ compiler's capabilities are currently missing, such that CXXFLAGS lack the ABI- and machine-specific flags (-m32/-m64, -march=.../-mtune=...). -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Re: Progress towards the release
On 28.03.2014 19:36, Bill Hart wrote: I've added it to the list. I'm puzzled as to how this bug has lasted until now to be reported. It must surely have broken things on a lot of C++ platforms, and it almost certainly has never been right. With MPIR 2.6.0 (and presumably [m]any earlier version[s]) this worked for me (although I usally set CXXFLAGS manually, so wouldn't notice unless I'm explicitly testing or compiling the C++ interface for a non-default ABI): ... checking ABI=64 checking whether gcc-4.7.0 is gcc... yes checking compiler gcc-4.7.0 -m64 ... yes checking compiler gcc-4.7.0 -m64 -O2... yes checking compiler gcc-4.7.0 -m64 -O2 -march=btver1... yes checking compiler gcc-4.7.0 -m64 -O2 -march=btver1 -mtune=btver1... yes checking for gcc... gcc-4.7.0 checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc-4.7.0 accepts -g... yes checking for gcc-4.7.0 option to accept ISO C89... none needed ... checking for gcc... (cached) gcc-4.7.0 checking whether we are using the GNU C compiler... (cached) yes checking whether gcc-4.7.0 accepts -g... (cached) yes checking for gcc-4.7.0 option to accept ISO C89... (cached) none needed checking for gcc-4.7.0 option to accept ISO C99... -std=gnu99 checking for gcc-4.7.0 -std=gnu99 option to accept ISO Standard C... (cached) -std=gnu99 checking how to run the C preprocessor... cpp-4.7.0 checking build system compiler gcc-4.7.0 -std=gnu99... yes checking for build system preprocessor... gcc-4.7.0 -std=gnu99 -E checking for build system executable suffix... checking whether build system compiler is ANSI... yes checking for build system compiler math library... -lm checking whether we are using the GNU C++ compiler... yes checking whether g++-4.7.0 accepts -g... yes checking C++ compiler g++-4.7.0 -m64 -O2 -march=btver1 -mtune=btver1... yes checking how to run the C++ preprocessor... g++-4.7.0 -E using ABI=64 CC=gcc-4.7.0 -std=gnu99 CFLAGS=-m64 -O2 -march=btver1 -mtune=btver1 CPPFLAGS= CXX=g++-4.7.0 CXXFLAGS=-m64 -O2 -march=btver1 -mtune=btver1 MPN_PATH= x86_64/bobcat x86_64 generic ... -leif On 28 March 2014 18:42, leif not.rea...@online.de mailto:not.rea...@online.de wrote: On 24.03.2014 17 tel:24.03.2014%2017:17, Bill Hart wrote: I have now assigned 36 open tickets to the 2.7 release. I'm sure more will be added, but at least we now have some measure of how far we are from a release. Just in case that's not yet on the todo list: While --enable-cxx (and 'make check' with that) meanwhile works, apparently the checks for the C++ compiler's capabilities are currently missing, such that CXXFLAGS lack the ABI- and machine-specific flags (-m32/-m64, -march=.../-mtune=...). -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Re: Progress towards the release
On 29.03.2014 00:09, Bill Hart wrote:
Hmm, autoconf 2.69 doesn't fix this problem either. Screwed if I know
how CXXFLAGS gets populated.
I *think* this is pretty unrelated to the autotools version; you simply
moved AC_PROG_CXX up (in configure.ac), but not the prior test which is
supposed to record whether CXXFLAGS had been set (by the user!):
test_CXXFLAGS=${CXXFLAGS+set}
AC_PROG_CXX of course modifies / sets CXXFLAGS, such that test_CXXFLAGS
now always equals set, so MPIR assumes *the user* had set them, and
hence never tries to modify them.
So it should be sufficient to either move AC_PROG_CXX back down, the
test for user-set CXXFLAGS up (right /before/ AC_PROG_CXX), or --
presumably less robust -- to use one of the autoconf-saved values,
ac_test_CXXFLAGS (instead of test_CXXFLAGS), or ac_save_CXXFLAGS
(instead of CXXFLAGS).
-leif
On 28 March 2014 22:46, Bill Hart goodwillh...@googlemail.com
mailto:goodwillh...@googlemail.com wrote:
I think it's a new autotools bug. It certainly should set CXXFLAGS
appropriately, but doesn't. And we've not changed that part of
configure.ac http://configure.ac. It also happens to be the same
as in GMP, which does get the right CXXFLAGS.
Fortunately I have to issue the release with a different version of
autotools anyway, as the Ubuntu version doesn't support Windows, etc.
So perhaps you can check again when I do that.
Bill.
On 28 March 2014 21:43, leif not.rea...@online.de
mailto:not.rea...@online.de wrote:
On 28.03.2014 19:36, Bill Hart wrote:
I've added it to the list.
I'm puzzled as to how this bug has lasted until now to be
reported. It
must surely have broken things on a lot of C++ platforms,
and it almost
certainly has never been right.
With MPIR 2.6.0 (and presumably [m]any earlier version[s]) this
worked for me (although I usally set CXXFLAGS manually, so
wouldn't notice unless I'm explicitly testing or compiling the
C++ interface for a non-default ABI):
...
checking ABI=64
checking whether gcc-4.7.0 is gcc... yes
checking compiler gcc-4.7.0 -m64 ... yes
checking compiler gcc-4.7.0 -m64 -O2... yes
checking compiler gcc-4.7.0 -m64 -O2 -march=btver1... yes
checking compiler gcc-4.7.0 -m64 -O2 -march=btver1
-mtune=btver1... yes
checking for gcc... gcc-4.7.0
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc-4.7.0 accepts -g... yes
checking for gcc-4.7.0 option to accept ISO C89... none needed
...
checking for gcc... (cached) gcc-4.7.0
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc-4.7.0 accepts -g... (cached) yes
checking for gcc-4.7.0 option to accept ISO C89... (cached) none
needed
checking for gcc-4.7.0 option to accept ISO C99... -std=gnu99
checking for gcc-4.7.0 -std=gnu99 option to accept ISO Standard
C... (cached) -std=gnu99
checking how to run the C preprocessor... cpp-4.7.0
checking build system compiler gcc-4.7.0 -std=gnu99... yes
checking for build system preprocessor... gcc-4.7.0 -std=gnu99 -E
checking for build system executable suffix...
checking whether build system compiler is ANSI... yes
checking for build system compiler math library... -lm
checking whether we are using the GNU C++ compiler... yes
checking whether g++-4.7.0 accepts -g... yes
checking C++ compiler g++-4.7.0 -m64 -O2 -march=btver1
-mtune=btver1... yes
checking how to run the C++ preprocessor... g++-4.7.0 -E
using ABI=64
CC=gcc-4.7.0 -std=gnu99
CFLAGS=-m64 -O2 -march=btver1 -mtune=btver1
CPPFLAGS=
CXX=g++-4.7.0
CXXFLAGS=-m64 -O2 -march=btver1 -mtune=btver1
MPN_PATH= x86_64/bobcat x86_64 generic
...
-leif
On 28 March 2014 18:42, leif not.rea...@online.de
mailto:not.rea...@online.de
mailto:not.rea...@online.de mailto:not.rea...@online.de
wrote:
On 24.03.2014 17 tel:24.03.2014%2017
tel:24.03.2014%2017:17, Bill Hart wrote:
I have now assigned 36 open tickets to the 2.7
release. I'm sure
more
will be added, but at least we now have some
measure of how far
we are
from a release
Re: [mpir-devel] Re: Access to Atom and recent AMD (bobcat) -- MPIR tuning values badly needed!!
Bill Hart wrote: Leif said he was going to tune on a bobcat, but hasn't yet. Well, this of course^TM turned out to be a can of worms... ;-) So far it looks like the bobcat version of mpn_sqr_basecase was actually faster, but I don't really trust the figures. (I played a little with the precision option, but this seems to be logically limited to 2^31. With the default precision, I occasionally get non-monotonic numbers; not that one value was exceptionally bad -- as one would expect, but timings about twice as fast, despite both cores being on performance, and the machine mostly idle.) Still have to analyze how reliable individual thresholds are. -leif That may be because I mentioned there is an additional step for the bobcat. We need to know if mpn/x86_64/bobcat/sqr_basecase.as http://sqr_basecase.as or mpn/x86_64/sqr_basecase.asm is faster. This can be determined by running: ./configure make make clean cd tune make speed ./speed -s 1-40 mpn_sqr_basecase before and after deleting mpn/x86_64/bobcat/sqr_basecase.as http://sqr_basecase.as Assuming it is faster after deleting it (smaller numbers are better -- and we assume they will be smaller), run make tune and send the results to us. Actually, I just realised, we'd like to know the same thing about mpn/x86_64/atom/sqr_basecase.as http://sqr_basecase.as on the atom. Bill. On 24 March 2014 11:12, Frithjof Schulze sfrith...@gmail.com mailto:sfrith...@gmail.com wrote: On Friday, March 21, 2014 5:37:16 PM UTC, Bill Hart wrote: Note MPIR will run very slow on these machines without proper tuning values due to significant recent changes. So we'd appreciate any help. We can also tell you how to do the tuning yourself and send us the values (it's really easy). I have a netbook with an E-350 and also an older atom based netbook. I could tune MPIR on both, if nobody has done so yet. --Frithjof -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] test failure: t-scan
Bill Hart wrote: Thanks Alfred, this is a known bug which has been fixed in our repository. We are working on a new release which will also not have this bug. It's still at least a couple of weeks away, but shouldn't be too long now I hope. Bill. One may add that it's just a trivial bug (one-character fix, see link below [1]) in the test code, not the MPIR library itself, which incidentally never showed up until GCC 4.8 came out. -leif [1] https://groups.google.com/d/msg/mpir-devel/oLk3gMULxu0/RJD3yMpdMKkJ On 21 March 2014 12:50, Alfred Thompson athomp...@hortonworks.com mailto:athomp...@hortonworks.com wrote: I write to tell you of a test failure I found in compiling mpir-2.6.0. This build was compiled on macosx 10.9.2 (Darwin Kernel Version 13.1.0) with gcc-4.8.2, gmp-5.1.3, mpfr-3.1.2, mpc-1.0.2. The compiler and libraries are all custom-built on this host. /bin/sh: line 1: 47678 Bus error: 10 $tst t-scan.log-t 21 FAIL: t-scan Here is relevant section of tests/mpz/test-suite.log: == MPIR 2.6.0: tests/mpz/test-suite.log == 1 of 66 tests failed. .. contents:: :depth: 2 FAIL: t-scan (exit: 138) -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Re: Progress towards the release
Bill Hart wrote: I have now tuned on the following architectures: core2, penryn, k102, netburst, k8, k10, bulldozer, westmere, sandybridge, piledriver, nehalem, core2, ia64. I don't have tuning values for: x86 (any kind), bobcat, atom, arm, mips32, mips64, sparc32, sparc64, ppc32, ppc64. If anyone can contribute any of the above, please do. Bill. Fresh tuning values for Bobcat (AMD E-450) are on the way; I've meanwhile run tuneup 20 times while the machine was otherwise idle... (GCC 4.8.0 on Ubuntu 10.04.4 x86_64, FWIW). I'll presumably provide tuning values for Pentium 4 Prescott (x86) tomorrow; MPIR's current cpuid.c still (mis-)detects that CPU (family 15 model 3; same for model 4) as a stock Pentium 4 though. There's currently no special assembly code for Prescott (using SSE3/PNI, say), but GCC is fed with '-march=pentium4 -mtune=pentium4' instead of '-march=prescott -mtune=prescott'. If it's of any use, I could also try to revive a Pentium III (Coppermine) and tune on that. -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] Tuning help needed
Bill Hart wrote:
Hi all,
I have finally finished with all the new tuning code for the new release.
If you'd like to help with tuning that would be great.
It's just make tune in the tune directory, using the latest from our
git repo (https://github.com/wbhart/mpir -- if you don't have git,
there is a Download Zip option on the right hand side of that page).
Just send me the result. Also tell me what config.guess returns so I
know what machine you have.
We need tuning values for as many diverse architectures as possible.
Hmmm, when building in a separate directory, 'configure' bails out
because it tries to run .../yasm/config/config.{guess,sub} from the
/source/ tree, but these files are only present in / put into the
/build/ tree.
Worse, with '--enable-cxx', 'make check' fails due to a build error on
the first C++ test file:
Making check in cxx
make[3]: Entering directory
`/data/leif/scratch/mpir-master-20140320-build.gcc-4.4.3-default/tests/cxx'
make t-assign t-binary t-cast t-constr t-headers t-istream t-locale
t-misc t-ops t-ostream t-prec t-rand t-ternary t-unary
make[4]: Entering directory
`/data/leif/scratch/mpir-master-20140320-build.gcc-4.4.3-default/tests/cxx'
g++ -DHAVE_CONFIG_H -I. -I../../../../src/mpir-master-20140320/tests/cxx
-I../.. -I../../../../src/mpir-master-20140320
-I../../../../src/mpir-master-20140320/tests-g -O2 -c -o t-assign.o
../../../../src/mpir-master-20140320/tests/cxx/t-assign.cc
In file included from
../../../../src/mpir-master-20140320/tests/cxx/t-assign.cc:26:
../../../../src/mpir-master-20140320/mpirxx.h:1389: error: 'common_type'
is not a template
../../../../src/mpir-master-20140320/mpirxx.h:1398: error: wrong number
of template arguments (2, should be 4)
../../../../src/mpir-master-20140320/mpirxx.h:1389: error: provided for
'templateclass T, class U, class V, class W struct std::common_type'
../../../../src/mpir-master-20140320/mpirxx.h:1416: error: wrong number
of template arguments (2, should be 4)
../../../../src/mpir-master-20140320/mpirxx.h:1389: error: provided for
'templateclass T, class U, class V, class W struct std::common_type'
../../../../src/mpir-master-20140320/mpirxx.h:1416: error: wrong number
of template arguments (2, should be 4)
../../../../src/mpir-master-20140320/mpirxx.h:1389: error: provided for
'templateclass T, class U, class V, class W struct std::common_type'
../../../../src/mpir-master-20140320/mpirxx.h:1417: error: wrong number
of template arguments (2, should be 4)
../../../../src/mpir-master-20140320/mpirxx.h:1389: error: provided for
'templateclass T, class U, class V, class W struct std::common_type'
[lots of similar errors]
(With both Ubuntu GCC 4.4.3 as well as FSF GCC 4.8.2, FWIW.)
But probably you're already aware of that and I just missed some
discussion -- sorry for the noise in that case.
Anyway, the other tests all passed on a Bobcat (aka btver1) and a
Piledriver (aka bdver2), both Ubuntu 10.04.4, and I couldn't provide
meaningful tuning values right now either (because of heavy sysload);
I'll hopefully be able to submit some the next days.
Cheers,
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.
Re: [mpir-devel] make.bat check failed on winxp/vs2008/mpir-2.6.0
Brian Gladman wrote: On 24/06/2013 15:10, Bill Hart wrote: Hi, I recall we had a warning related to ___gmpn_preinv_mod_1 which got fixed before the mpir-2.6.0 release. But despite this sounding like a familiar problem, I haven't been able to find a post where it was dealt with in the past. Can you post a copy of your config.h to help us get to the bottom of it. Perhaps Brian has some idea what is going on here. However, I am not sure if we are supporting vs2008 any more. We do through the command line build that Jason provided but this is now unsupported. I have sometimes seen this problem when a build uses old configuration files so it might be worth checking that a full clean has been done before the build is started. Shooting into the dark: Isn't probably just the MPN_PATH wrong (opposite order, such that it doesn't match the definitions in config.h, especially HAVE_NATIVE_mpn_preinv_mod_1, which is 1): (set MPNPATH=x86w x86w\p6 x86w\p6\mmx x86w\p6\p3mmx) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [mpir-devel] make.bat check failed on winxp/vs2008/mpir-2.6.0
leif wrote: Brian Gladman wrote: On 24/06/2013 15:10, Bill Hart wrote: Hi, I recall we had a warning related to ___gmpn_preinv_mod_1 which got fixed before the mpir-2.6.0 release. But despite this sounding like a familiar problem, I haven't been able to find a post where it was dealt with in the past. Can you post a copy of your config.h to help us get to the bottom of it. Perhaps Brian has some idea what is going on here. However, I am not sure if we are supporting vs2008 any more. We do through the command line build that Jason provided but this is now unsupported. I have sometimes seen this problem when a build uses old configuration files so it might be worth checking that a full clean has been done before the build is started. Shooting into the dark: Isn't probably just the MPN_PATH wrong (opposite order, such that it doesn't match the definitions in config.h, especially HAVE_NATIVE_mpn_preinv_mod_1, which is 1): (set MPNPATH=x86w x86w\p6 x86w\p6\mmx x86w\p6\p3mmx) P.S.: ___gmpn_preinv_mod_1 is implemented in x86w/p6, but now x86w. And/or: Maybe just a typo in MPNPATH (should be MPN_PATH on Windows as well I guess). -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [mpir-devel] make.bat check failed on winxp/vs2008/mpir-2.6.0
Brian Gladman wrote: On 24/06/2013 16:10, leif wrote: leif wrote: Brian Gladman wrote: On 24/06/2013 15:10, Bill Hart wrote: Hi, I recall we had a warning related to ___gmpn_preinv_mod_1 which got fixed before the mpir-2.6.0 release. But despite this sounding like a familiar problem, I haven't been able to find a post where it was dealt with in the past. Can you post a copy of your config.h to help us get to the bottom of it. Perhaps Brian has some idea what is going on here. However, I am not sure if we are supporting vs2008 any more. We do through the command line build that Jason provided but this is now unsupported. I have sometimes seen this problem when a build uses old configuration files so it might be worth checking that a full clean has been done before the build is started. Shooting into the dark: Isn't probably just the MPN_PATH wrong (opposite order, such that it doesn't match the definitions in config.h, especially HAVE_NATIVE_mpn_preinv_mod_1, which is 1): (set MPNPATH=x86w x86w\p6 x86w\p6\mmx x86w\p6\p3mmx) P.S.: ___gmpn_preinv_mod_1 is implemented in x86w/p6, but now x86w. And/or: Maybe just a typo in MPNPATH (should be MPN_PATH on Windows as well I guess). It is MPNPATH in Jason's command line build files. Ah, I see. And I actually thought the (set ...) commands were typed manually, but they're actually generated by configure.bat... -- sorry for the noise. :-) The order of the folders in MPNPATH is correct, and we even have :: dont know what the asm version have so delete them del preinv_divrem_1.obj preinv_mod_1.obj divrem_1.obj mod_1.obj divrem_euclidean_qr_1.obj nul 21 cl %OPT% -I..\.. ..\..\mpn\generic\divrem_1.c if errorlevel 1 goto :err cl %OPT% -I..\.. ..\..\mpn\generic\mod_1.c if errorlevel 1 goto :err cl %OPT% -I..\.. ..\..\mpn\generic\divrem_euclidean_qr_1.c if errorlevel 1 goto :err cl /D USE_PREINV_DIVREM_1 %OPT% -I..\.. ..\..\mpn\generic\preinv_divrem_1.c if errorlevel 1 goto :err cl %OPT% -I..\.. ..\..\mpn\generic\preinv_mod_1.c if errorlevel 1 goto :err in make.bat, but also #if !HAVE_NATIVE_mpn_preinv_mod_1 /* This function used to be documented, but is now considered obsolete. It continues to exist for binary compatibility, even when not required internally. */ mp_limb_t mpn_preinv_mod_1 (mp_srcptr up, mp_size_t un, mp_limb_t d, mp_limb_t dinv) ... in mpn/generic/preinv_mod_1.c, such that this indeed doesn't work with the setting in config.h (where HAVE_NATIVE_mpn_preinv_mod_1 was set to 1). So just turning that 1 into 0 in config.h and rerunning make.bat /should/^TM work... And upstream should probably change the line in win/make.bat to cl /D USE_PREINV_MOD_1 %OPT% -I..\.. ..\..\mpn\generic\preinv_mod_1.c and mpn/generic/preinv_mod_1.c accordingly: #if !HAVE_NATIVE_mpn_preinv_mod_1 || defined(USE_PREINV_MOD_1) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [mpir-devel] make.bat check failed on winxp/vs2008/mpir-2.6.0
redp wrote: hi I have sometimes seen this problem when a build uses old configuration files so it might be worth checking that a full clean has been done before the build is started. but after make clean config.h is also removed and more worse - even if you patch string #define HAVE_NATIVE_mpn_preinv_mod_1 1 in config.h - it will be rewritten during make Ooops? Then it seems you'd have to make the upstream changes I suggested in my previous post (or just change the #if !HAVE_NATIVE_mpn_preinv_mod_1 temporarily to #if 1 for your build). -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [mpir-devel] MPIR fails a bunch of tests on Cygwin64
Jean-Pierre Flori wrote: I've reported the problem to the Cygwin folk at http://cygwin.com/ml/cygwin/2013-06/msg00539.html. Nice. Is it always 'ld' that crashes? I'd guess that yasm is to blame (probably not yet fully prepared for Cygwin64*), somehow generating invalid object files that cause (e.g.) 'ld' to crash. Did you try to use some other tools (using the BFD library) on the offending object files? (The archives in contrast are probably ok, although perhaps not all object files they contain.) -leif *(at least not the version currently shipped with MPIR) On 20 June 2013 10:40, Jean-Pierre Flori jpf...@gmail.com javascript: wrote: Dear all, I've been trying MPIR (after updating configfsf.* in src and config.* in yasm/config/) on Cygwin64 and a lot of tests (but not all of them) fail. I had no time (and surely won't before a few days/weeks) to run gdb on them but any hint would be welcomed. Best, JP -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [mpir-devel] MPIR fails a bunch of tests on Cygwin64
leif wrote: I'd guess that yasm is to blame (probably not yet fully prepared for Cygwin64*), somehow generating invalid object files that cause (e.g.) 'ld' to crash. Just noticed both Cygwin(64) and MPIR 2.6.0 have yasm 1.2.0, but it looks as if Cygwin would patch it (from the package version). You may try to use Cygwin's yasm, or look whether they do anything significant to its vanilla sources. (At any rate, surely 'ld' shouldn't segfault even if yasm was the culprit...) Or experiment a little with --host=... (i.e., the CPU type, such that other [assembly] files / a different MPN_PATH is chosen). -leif Did you try to use some other tools (using the BFD library) on the offending object files? (The archives in contrast are probably ok, although perhaps not all object files they contain.) -leif *(at least not the version currently shipped with MPIR) -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [mpir-devel] MPIR fails a bunch of tests on Cygwin64
leif wrote: leif wrote: I'd guess that yasm is to blame (probably not yet fully prepared for Cygwin64*), somehow generating invalid object files that cause (e.g.) 'ld' to crash. Just noticed both Cygwin(64) and MPIR 2.6.0 have yasm 1.2.0, but it looks as if Cygwin would patch it (from the package version). You may try to use Cygwin's yasm, or look whether they do anything significant to its vanilla sources. Hmmm, doesn't look like, or at least I couldn't find anything relevant. Perhaps GCC miscompiles it on your machine... Could you post a configure+build[+make check] log somewhere (e.g. Sage trac ticket #14648)? -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [mpir-devel] MPIR 2.6.0 does not build with clang
Jeroen Demeyer wrote: On 06/03/2013 01:41 PM, Bill Hart wrote: Using plain malloc will incur a performance penalty on many versions of gcc Does that really matter for the configure script? Not performance, but the brokenness to test might actually be related to the use of GCC's *built-in* malloc(). -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [mpir-devel] Configuring fails on Cygwin64
Jean-Pierre Flori wrote:
On Sunday, May 26, 2013 9:43:31 PM UTC+2, leif wrote:
Jean-Pierre Flori wrote:
Dear all,
The Cygwin folks are working hard on Cygwin64.
I tried to install MPIR 2.6.0 on top of that but the config.guess
shipped with MPIR failed when trying to get where it was building
on.
In fact this file is quite old, from 2003 according to the timestamp
spit within the error message, the latest upstream seems to be
frequently updated.
Using the latest upstream config.guess (in top level dir, yasm and
yasm/config subdirs, I also updated config.sub) let MPIR
configure (and
then build, I cannot promise the result is functional though yet).
For the top-level dir, I assume you're talking about
configfsf.{guess,sub}.
You may still have to modify the top-level config.guess as well though.
Don't really know, it's late here so I just replaced the config.* files
as suggested by the error message without giving it more thoughts and it
just worked.
The generic config.{guess,sub} alone are pretty useless for GMP/MPIR and
the like, as they don't return / support any specific CPU type (beyond
what usually 'uname -m' or 'uname -p' gives).
Just take a look at the original files; they're wrappers around the
generic ones (which have been renamed to configfsf.*).
I did not try to autoreconf
That's not necessary.
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [mpir-devel] t-scan test crashes, mpir 2.6.0, mac os x, gcc 4.8.0
Daniel R. Grayson wrote: I'll try it. Sorry, I was probably a bit too quick... On Tue, Apr 2, 2013 at 11:16 AM, leif not.rea...@online.de mailto:not.rea...@online.de wrote: Daniel R. Grayson wrote: The t-scan test crashes, in mpir 2.6.0, under mac os x, with gcc 4.8.0. /bin/sh: line 1: 73249 Segmentation fault: 11 $tst t-scan.log-t 21 FAIL: t-scan Confirmed on Linux x86_64, released FSF GCC 4.8.0, default CFLAGS. Note that mpz/t-scan segfaults, mpn/t-scan passes (for me). -leif $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/__local/encap/gcc-trunk/libexec/__gcc/x86_64-apple-darwin12.0.0/__4.8.0/lto-wrapper Target: x86_64-apple-darwin12.0.0 Configured with: ../trunk/configure --prefix=/usr/local/encap/gcc-__trunk --enable-languages=c,c++ Thread model: posix gcc version 4.8.0 20120805 (experimental) (GCC) Haven't tried on Darwin yet, but GCC 4.8.0 (final) has been released on March 22nd. -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [mpir-devel] Some Sage user having trouble installing MPIR on 32 bits archs
Bill Hart wrote: Yes, it looks like you are right. I've added it to the MPIR todo list to fix this in our configure. Thanks. Let us know when an upstream patch is available. (The easiest work-around for the Sage spkg is perhaps just unsetting ABI if config.guess matches core-*.) Not sure which code paths should be selected for the Intel Core (on 32-bit systems at least x86), and whether other CPUs are missing (besides the Pentium4 Prescott, as mentioned). It is btw reproducible on other (capable, x86/x86_64) systems: $ ../mpir-2.6.0/configure -v --host=core-pc-linux-gnu ... checking ABI=standard checking compiler core-pc-linux-gnu-gcc -O2 ... no checking compiler gcc -O2 ... yes checking for core-pc-linux-gnu-gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no ... using ABI=standard CC=gcc -std=gnu99 CFLAGS=-O2 CPPFLAGS= MPN_PATH= generic ... (Note the MPN path.) $ ../mpir-2.6.0/configure -v --host=core-pc-linux-gnu ABI=32 configure: WARNING: if you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used checking build system type... bobcat-unknown-linux-gnu checking host system type... core-pc-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for core-pc-linux-gnu-strip... no checking for strip... strip checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no configure: error: ABI=32 is not among the following valid choices: standard As for fat binary, sure, if the user requests it, no problem. I don't warrant it'll work on arbitrary systems though. I just thought this was the default for any Sage build on a 32 bit x86, which would be wrong. Well, we use it when building the Sage binary distributions, too, but people are encouraged to build from source anyway... (Still many users seem to prefer just grabbing these, unfortunately.) -leif On 24 February 2013 17:37, leif not.rea...@online.de wrote: Bill Hart wrote: Is it passing --enable-fat to MPIR's configure? If it is, then it shouldn't be. If SAGE_FAT_BINARY=yes (set by the user, on Linux x86/x86_64 only IIRC). Why shouldn't we? But the real problem here seems to be an upstream (i.e., MPIR) bug: While config.guess yields core-pc-linux-gnu on the failing system, 'core[-*]' isn't handled by MPIR's configure (such that abilist finally contains only the dummy value, not '32', which we request): ... # abilist needs to be non-empty, standard is just a generic name here abilist=standard ... case $host in # from config.guess (Sage doesn't configure with --host=... or the like) ... # AMD and Intel x86 configurations, including AMD64 # # Rumour has it gcc -O2 used to give worse register allocation than just # -O, but lets assume that's no longer true. # # -m32 forces 32-bit mode on a bi-arch 32/64 amd64 build of gcc. -m64 is # the default in such a build (we think), so -m32 is essential for ABI=32. # This is, of course, done for any $host_cpu, not just x86_64, so we can # get such a gcc into the right mode to cross-compile to say i486-*-*. # # -m32 is not available in gcc 2.95 and earlier, hence cflags_maybe to use # it when it works. We check sizeof(long)==4 to ensure we get the right # mode, in case -m32 has failed not because it's an old gcc, but because # it's a dual 32/64-bit gcc without a 32-bit libc, or whatever. # i?86*-*-* | k[5-8]*-*-* | pentium*-*-* | athlon-*-* | viac3*-*-* | x86_64-*-* | netburst-*-* | netburstlahf-*-* | k8-*-* | k10-*-* | k102-*-* | k103-*-* | core2-*-* | penryn-*-* | nehalem-*-* | westmere-*-* | sandybridge-*-* | atom-*-* | nano-*-* | bobcat-*-* | bulldozer-*-*) abilist=32 cclist=gcc icc cc gcc_cflags=-O2 $fomit_frame_pointer case $host in *-*-linux-gnu) gcc_32_ldflags=-Wl,-z,noexecstack ;; esac gcc_32_cflags_maybe=-m32 icc_cflags=-no-gcc icc_cflags_optlist=opt icc_cflags_opt=-O3 -O2 -O1 any_32_testlist=sizeof-long-4 CALLING_CONVENTIONS_OBJS='x86call.lo x86check$U.lo' ... case $host_cpu in i386*) path=x86/i386 x86 ;; i486*) path=x86/i486 x86 ;; i586 | pentium) path=x86/pentium x86 ;; pentiummmx) path=x86/pentium/mmx x86/pentium x86 ;; i686 | pentiumpro) path=x86/p6 x86 ;; pentium2)path=x86/p6/mmx x86/p6 x86 ;; pentium3)path=x86/p6/p3mmx x86/p6/mmx x86/p6 x86;; k6[23])path=x86/k6/k62mmx x86/k6/mmx x86/k6 x86 ;; k6
Re: [mpir-devel] Re: Compiling MPIR for Win64 with MinGW64
exc...@live.fr wrote: Thanks for you answers. You may be hitting compiler bugs. The early compiler revisions in a series tend to cause test failures with MPIR. FWIW, on Linux x86_64 (Bobcat), MPIR 2.6.0 compiles just fine with vanilla FSF GCC 4.7.0, i.e., passes all tests with -O2 (default) as well as with [-march=native and] -O3, including the C++ interface. (My impression is that GCC 4.7.0 is less broken than other .0 releases, at least on x86/x86_64.) -leif I think it compiles ok with gcc 4.6.3, though things are often more broken on MinGW64 than Linux. Unfortunately, TDM-GCC only have early compiler revisions ( http://sourceforge.net/projects/tdm-gcc/files/TDM-GCC%20Installer/Previous/1.1006.0/ ). Is there any other easy way to install MinGW64 on Windows? Don't use O3, I guess ;-) Where did that O3 come from ? When I build mpir-2.6.0 for Win64 (gcc-4.7.0), -O2 is the (default) optimisation level that's used - and there's no problem with the build and the tests for that level. I haven't actually tried -O3, though I probably could (if you tell me how to do that :-) I had put the -O3 by hand after the configure step. Even with -O2, it is still failing (but less): PASS: t-addadd_n.exe PASS: t-addsub_n.exe PASS: t-aors_1.exe PASS: t-asmtype.exe PASS: t-dc_bdiv_q.exe PASS: t-dc_bdiv_q_n.exe PASS: t-dc_bdiv_qr.exe PASS: t-dc_bdiv_qr_n.exe PASS: t-dc_div_q.exe PASS: t-dc_div_qr.exe PASS: t-dc_div_qr_n.exe PASS: t-dc_divappr_q.exe PASS: t-dc_divappr_q_n.exe PASS: t-divebyff.exe PASS: t-divebyfobm1.exe PASS: t-divrem_1.exe PASS: t-fat.exe PASS: t-gcdext.exe FAIL: t-get_d.exe PASS: t-hgcd.exe PASS: t-instrument.exe PASS: t-inv_div_q.exe PASS: t-inv_div_qr.exe PASS: t-inv_div_qr_n.exe PASS: t-inv_divappr_q.exe PASS: t-inv_divappr_q_n.exe PASS: t-invert.exe PASS: t-iord_u.exe PASS: t-lorrshift1.exe PASS: t-matrix22.exe PASS: t-mp_bases.exe PASS: t-mullow_basecase.exe PASS: t-mullowhigh.exe PASS: t-mulmid.exe PASS: t-mulmod_2expm1.exe PASS: t-mulmod_2expp1.exe PASS: t-neg.exe PASS: t-perfsqr.exe PASS: t-redc_1.exe PASS: t-sb_bdiv_q.exe PASS: t-sb_bdiv_qr.exe PASS: t-sb_div_q.exe PASS: t-sb_div_qr.exe PASS: t-sb_divappr_q.exe PASS: t-scan.exe PASS: t-subadd_n.exe PASS: t-tdiv_q.exe PASS: t-tdiv_qr.exe = 1 of 48 tests failed See tests/mpn/test-suite.log Please report to http://groups.google.co.uk/group/mpir-devel/ = -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[mpir-devel] Re: [sage-release] sage-5.6.beta2 released - MPIR's configure fails with clang and '-O0'
Jeroen Demeyer wrote:
On 2013-01-06 06:23, leif wrote:
Unless one specifies '-O2' or higher ('-finline*' doesn't work either),
the GNU __inline__ function doesn't get inlined, which is in principle
ok, but Clang doesn't emit code for it either, hence the linker error.
(FWIW, '-std=gnu*' doesn't seem to make any difference.)
If clang:
* doesn't inline e(),
* references the function e() as a function call,
* but doesn't actually generates code for e(),
I'd say that's a bug in clang.
Well, if you expect Clang to be fully compatible with GCC, then yes.
(Note that this only applies to GNU __inline__ functions, not C/C++
inline functions.)
Nevertheless, MPIR's failing 'configure' tests aren't meant for Clang
(and try to trigger other bugs, in particular of broken *GCC* versions),
and pretty easy to fix. [I've so far successfully built 32-bit and
64-bit versions of MPIR 2.6.0 with Clang 3.1 (incidentally also with a
mixture of 'clang' and 'g++'), with '-O0' as well as (implicitly) '-O2';
'make check' passed in each case. That's still on Linux though; I'll
try what happens on MacOS X later.]
I'm [currently] not intending to make Sage fully build with Clang, but
IMHO bootstrapping our GCC should work with Clang as well (including the
case when SAGE_DEBUG happens to be set to yes). (Not yet sure about
Apple's /old/ Clang 1.7. On MacOS X systems with that version, we can
probably rely on -- or, more precisely, require -- [at least] Apple's
GCC 4.0.1 or 4.2.1.)
I think if MPIR 2.6.0 gets into Sage within reasonable time, we don't
need to fix our 2.4.0 spkg, although doing so is trivial (just a matter
of time...).
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: [sage-release] sage-5.6.beta2 released - MPIR's configure fails with clang and '-O0'
leif wrote:
Ivan Andrus wrote:
On Jan 5, 2013, at 8:03 PM, leif not.rea...@online.de wrote:
Ivan Andrus wrote:
Dear Sagephiles,
Sorry to be so late to the party, but I tried building recently and
noticed that building MPIR fails with SAGE_DEBUG=yes. This is
before a new gcc has been installed. It compiled fine once I set
SAGE_DEBUG to the empty string.
I'm using OS X 10.8.2 with a Mid 2010 MacBook Pro. The build log is at
http://boxen.math.washington.edu/home/iandrus/mpir-2.4.0.p6.log
Could you also upload MPIR's corresponding config.log
($SAGE_ROOT/spkg/build/mpir-2.4.0.p6/src/config.log IIRC)? (That of
a /failed/ build with Clang of course ;-) )
http://boxen.math.washington.edu/home/iandrus/config.log
Thanks. Although the 'configure' test is supposed to detect something
completely different, it fails due to some bug in Clang (or at least an
incompatibility to GCC / GNU C).
Unless one specifies '-O2' or higher ('-finline*' doesn't work either),
the GNU __inline__ function doesn't get inlined, which is in principle
ok, but Clang doesn't emit code for it either, hence the linker error.
(FWIW, '-std=gnu*' doesn't seem to make any difference.)
We could tweak the test to use 'extern inline' (although I'm not sure
whether that would still trigger the bug the test is meant for), or change
#ifdef__GNUC__
to
#ifdefined(__GNUC__) !defined(__clang__)
(The latter is IMHO more appropriate, regarding the intent of the test.)
MPIR versions 2.4 come with the same test, and since I know Bill is
keen to fix any Apple toolchain issues (although in this case it's
rather just Clang), it's likely we could get that upstream MPIR (cc'ed).
I probably spoke to soon, as I also run into other issues now (i.e.,
other 'configure' tests that don't work) while trying to build MPIR
2.6.0 with Clang (some 3.1 svn version at the moment).
More to come...
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR build and assembler used
Bill Hart wrote: There's a lot of mention of PPC in that thread. Obviously the applenopic stuff is for x86, not PPC. But then again, deleting the assembly files wouldn't work there either. So we really need the person who reported that to tell us the output of ./config.guess. And of course to tell us if the problem still happens when MPIR gets to choose the build target for itself. According to his log, Apple's assembler bails out on divexact_1.s, which is [made from] mpn/x86/divexact_1.asm (or x86/core2/divexact_1.asm), which contains ... ifdef(`PIC',` callL(movl_eip_edx) addl$_GLOBAL_OFFSET_TABLE_, %edx movlmodlimb_invert_table@GOT(%edx), %edx movzbl (%eax,%edx), %eax C inv 8 bits ',` dnl non-PIC movzbl modlimb_invert_table(%eax), %eaxC inv 8 bits ') ... Unfortunately, -DPIC is passed to m4 on his system: /bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4=m4 /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H-m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo divexact_1 | sed 's/_$//'` -I. -I.. `test -f 'divexact_1.asm' || echo './'`divexact_1.asm libtool: compile: ../mpn/m4-ccas --m4=m4 /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_divexact_1 -I. -I.. divexact_1.asm -fno-common -DPIC -o .libs/divexact_1.o m4 -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_divexact_1 -DPIC divexact_1.asm tmp-divexact_1.s /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_divexact_1 -I. -I.. tmp-divexact_1.s -fno-common -DPIC -o .libs/divexact_1.o tmp-divexact_1.s:119:junk `@GOT' after expression make[2]: *** [divexact_1.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Error building MPIR. -leif On 3 December 2012 13:19, Jean-Pierre Flori jpfl...@gmail.com wrote: With your hints I found https://groups.google.com/forum/?fromgroups=#!msg/mpir-devel/iSzn88nJO58/4efX1gWB5kIJ I'll ask for a full log on sage-devel. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR build and assembler used
Bill Hart wrote: I assume you mean divexact_1.asm. ? I don't think we set -DPIC anywhere, so I think this is an autotools bug. Presumably... ;-) How recent is the report? It might have been fixed by the latest autotools upgrade that we did. Well, the log is from an attempt to build Sage 5.4.1, which ships with MPIR 2.4.0[.p6.spkg], a few hours old IIRC... I actually haven't looked into the 2.6.0 sources, although I don't expect changes there (to the relevant asm files). The behavior appears to be the same with 2.4.0 and JP's 2.6.0 (I think). -leif On 3 December 2012 14:47, leif not.rea...@online.de wrote: Bill Hart wrote: There's a lot of mention of PPC in that thread. Obviously the applenopic stuff is for x86, not PPC. But then again, deleting the assembly files wouldn't work there either. So we really need the person who reported that to tell us the output of ./config.guess. And of course to tell us if the problem still happens when MPIR gets to choose the build target for itself. According to his log, Apple's assembler bails out on divexact_1.s, which is [made from] mpn/x86/divexact_1.asm (or x86/core2/divexact_1.asm), which contains ... ifdef(`PIC',` callL(movl_eip_edx) addl$_GLOBAL_OFFSET_TABLE_, %edx movlmodlimb_invert_table@GOT(%edx), %edx movzbl (%eax,%edx), %eax C inv 8 bits ',` dnl non-PIC movzbl modlimb_invert_table(%eax), %eaxC inv 8 bits ') ... Unfortunately, -DPIC is passed to m4 on his system: /bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4=m4 /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H-m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo divexact_1 | sed 's/_$//'` -I. -I.. `test -f 'divexact_1.asm' || echo './'`divexact_1.asm libtool: compile: ../mpn/m4-ccas --m4=m4 /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_divexact_1 -I. -I.. divexact_1.asm -fno-common -DPIC -o .libs/divexact_1.o m4 -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_divexact_1 -DPIC divexact_1.asm tmp-divexact_1.s /usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP -I.. -DOPERATION_divexact_1 -I. -I.. tmp-divexact_1.s -fno-common -DPIC -o .libs/divexact_1.o tmp-divexact_1.s:119:junk `@GOT' after expression make[2]: *** [divexact_1.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Error building MPIR. -leif On 3 December 2012 13:19, Jean-Pierre Flori jpfl...@gmail.com wrote: With your hints I found https://groups.google.com/forum/?fromgroups=#!msg/mpir-devel/iSzn88nJO58/4efX1gWB5kIJ I'll ask for a full log on sage-devel. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR build and assembler used
Jean-Pierre Flori wrote: On Monday, December 3, 2012 3:55:50 PM UTC+1, Bill Hart wrote: I assume you mean divexact_1.asm. I don't think we set -DPIC anywhere, so I think this is an autotools bug. How recent is the report? It might have been fixed by the latest autotools upgrade that we did. It's quite recent, from a few days ago, been tested with MPIR 2.6.0 (and 2.4.x with similar results). To make things clear : - this is with mac os 10.4 and 5 running in 32 bits mode on 64 bit intel hardware, so there is no PPC involved here, - we do not set PIC in the sage spkg, nor does MPIR itself, so it seems that some autotools magic decide to add it by default, Presumably. The problem is (at least) that it gets passed to m4 as well. [Not sure whether divexact_1 is incidentally just the *first* file (of probably a couple) Apple's as bails out.] - the problem is that MPIR then wants to use the corresponding asm files with PIC defined and these files use the @GOT construction that Apple's AS in this Mac OSes does not understand Not sure. Did you see his full log (i.e., the setting of MPN_PATH)? Note that there's no version of divexact_1 in the mpn/applenopic path, so [either mpn/x86/core2/divexact_1.asm or] mpn/x86/divexact_1.asm is chosen, no matter what. Both files contain conditional code, depending on the setting of the (m4) PIC macro. The error is apparently caused by autotools passing -DPIC[=1] to *m4*. Here is how we dealt with that before: delete all the problematic asm files, so that there is no @GOT anywhere and that did the trick. According to Bill, and if I understood correctly, that should not be necessary because autotools should detect its building MPIR on Mac OS on intel hardware and should choose the x86/applenopic subdirectory rather than the files from the x86 toplevel or say from the x86/core2 subdirectory which contain the @GOT construction. But that does not seem to be the case, files from other directories than the applenopic one are picked up here. See above. MPN_PATH (almost) always contains multiple directories, the files/implementations from the first which contains a file/implementation get chosen. Not sure what to think of the PIC thing. I guess it's quite natural that autotools tries to build PIC code by default if the system should be capable. The problem here is really that it also chooses files in a wrong directory and in the case of PIC code, the assembly files in this directory contain instructions that the assembler does not understand. Nope, I don't think so. (That's at least not the case for divexact_1.) As a temporary hack for the spkg, we could just patch out the conditional manually (as if PIC was set to zero) when building on that platform. Or invalidate -DPIC for m4 by other means... (m4-ccas script?) As mentioned, not sure whether it's just the *first* error Apple's as raises, but my guess is no. [Passing -DPIC to GCC doesn't hurt I think, as it knows how to properly handle that.] -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR build and assembler used
Jean-Pierre Flori wrote: Further info: - the result of ./config.guess is nehalem-apple-darwin9.8.0, which is not one dealt with in MPIR configure.in for the 32 bit apple darwin doesn't like our PIC format asm code. - and so we get MPN_PATH= x86/nehalem x86 generic ... then the -march=core-i7 was pretty correct. Who t** f*** runs a 32-bit operating system on such a machine? (Dual quad-core Xeon even IIRC) ;-) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR build and assembler used
Jean-Pierre Flori wrote: On Monday, December 3, 2012 6:13:57 PM UTC+1, leif wrote: Jean-Pierre Flori wrote: Further info: - the result of ./config.guess is nehalem-apple-darwin9.8.0, which is not one dealt with in MPIR configure.in http://configure.in for the 32 bit apple darwin doesn't like our PIC format asm code. - and so we get MPN_PATH= x86/nehalem x86 generic ... then the -march=core-i7 was pretty correct. Who t** f*** runs a 32-bit operating system on such a machine? (Dual quad-core Xeon even IIRC) ;-) I agree :) And that's the reason nobody complained until we explicitely pushed people to do so :) Well, YOU asked for it, so it's definitely your fault... ;-) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR build and assembler used
Jean-Pierre Flori wrote: On Monday, December 3, 2012 6:35:15 PM UTC+1, Bill Hart wrote: Time to apply the crumb test to JP's beard with a fine-toothed comb! By the way, shouldn't Sage be a little faster on my Amstrad PC1512? Bill. On 3 December 2012 17:29, leif not.r...@online.de javascript: wrote: Jean-Pierre Flori wrote: On Monday, December 3, 2012 6:13:57 PM UTC+1, leif wrote: Jean-Pierre Flori wrote: Further info: - the result of ./config.guess is nehalem-apple-darwin9.8.0, which is not one dealt with in MPIR configure.in http://configure.in http://configure.in for the 32 bit apple darwin doesn't like our PIC format asm code. - and so we get MPN_PATH= x86/nehalem x86 generic ... then the -march=core-i7 was pretty correct. Who t** f*** runs a 32-bit operating system on such a machine? (Dual quad-core Xeon even IIRC) ;-) I agree :) And that's the reason nobody complained until we explicitely pushed people to do so :) Well, YOU asked for it, so it's definitely your fault... ;-) -leif In fact I just wanted to get rid of the dirty piece of code in sage spkg install script and hoped that nobody would actually answer on sage-devel so that the removal gets undetected. How about changing # 32bit apple darwin doesn't like our PIC format asm code case $host in core2-apple-darwin* | penryn-apple-darwin*) path=x86/applenopic/core2 x86/applenopic ;; prescott-apple-darwin* | pentium4-apple-darwin*) path=x86/applenopic ;; pentium3-apple-darwin* | pentium2-apple-darwin*) path=x86/applenopic ;; i686-apple-darwin* | pentiumpro-apple-darwin*) path=x86/applenopic ;; core-apple-darwin*) path=x86/applenopic ;; *) ;; esac to just # 32bit apple darwin doesn't like our PIC format asm code case $host in core2-apple-darwin* | penryn-apple-darwin*) path=x86/applenopic/core2 x86/applenopic ;; *-apple-darwin*) path=x86/applenopic ;; *) ;; esac ? (As far as I can see, the above snippet is in the x86/x86_64 (and 32-bit OS/ABI) branch, so we don't have to deal with other archs than these there.) Otherwise the build will (sooner or later) fail in exactly the same way on newer CPUs on 32-bit Darwin. Btw, it would probably be better to use the applenopic/core2 path on any post-Core2 CPU as well. Then we'd have to invert the logic, such that the x86/applenopic/core2 path is *not* chosen / added on i[34567]86-|pentium*-|prescott-|core- (all with 'apple-darwin*' appended), but on everything else, hoping that the former list is complete. (We won't have to add CPUs to that list as time goes by, in contrast to the post-Core2 list.) For the sake of Sage, it's probably better to patch MPIR 2.6.0's 'configure' (i.e., the *generated* file) rather than 'configure.in' (autoreconfing afterwards, which usually causes lots of file changes) until 2.6.1 (with such a fix) is out. -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] problem with make check mpir 2.6.0
Bill Hart wrote: Yes, you should only get invalid instruction errors when it is compiling for the wrong machine. So either MPIR detected it incorrectly, or the virtual machine is configured incorrectly, or there is a compiler bug. The latter is a distinct possibility. gcc 4.6.0 is pretty buggy. I guess it's a VirtualBox problem, not being able to translate -- or rather not knowing -- the offending (presumably newer) instructions. Unless they originate from hand-written assembly code, you can also pass the desired target CPU type in CFLAGS, with '-march=...' and '-mtune=...'. (See GCC's documentation for valid arguments.) IIRC, /proc/cpuinfo (from within VirtualBox) may still show processor features VirtualBox doesn't support. You may also try MPIR's '--enable-fat' configure option, which makes MPIR to some extent select the used instruction set at run-time, although VirtualBox might still report the wrong CPU type there. -leif Bill. On 15 November 2012 15:22, Jean-Pierre Flori jpfl...@gmail.com wrote: On Thursday, November 15, 2012 9:13:40 AM UTC-6, Bill Hart wrote: Hi Elias, this might be to do with the virtual box, as we've tested on a large number of real machines and not encountered this yet. You may have to tell mpir's configure what the machine actually is by passing a --build=whatever Can you tell us what ./config.guess says on your system. Also, could you attach a copy of the config.log. Can you also attach the output of cat /proc/cpuinfo Thanks, Bill. On 15 November 2012 14:13, Elias elias.ts...@gmail.com wrote: Dear developers, when I do a make check with mpir 2.6.0, I get the following error /bin/bash: line 1: 17730 Illegal instruction (core dumped) $tst t-get_d.log-t 21 I am running lubuntu 12.10 using a virtual box in mac os lion. The compiler is gcc 4.6 Probably this causes problem in the installation of flint, but I will send another email for this. Can you please help me with this? best, -- Elias -- You received this message because you are subscribed to the Google Groups mpir-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/mpir-devel/-/YAi4NCxUpWAJ. To post to this group, send email to mpir-...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. I remember that we had problem with Sage built within Virtualbox, because although Virtualbox exposes the right type of processor and so gcc uses the right set of instructions, it does not really give you access to the complete set of instructions, whence potential SIGILL arising. Not sure how this was dealt with in Sage, but you might find some hints on sage-devel or the Sage's trac. Or this could be unrelated. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] problem with make check mpir 2.6.0
Elias wrote: Hi Bill, the ./config.guess gives sandybridge-unknown-linux-gnu the cpuinfo is processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2557M CPU @ 1.70GHz stepping: 7 cpu MHz : 1688.048 cache size : 6144 KB fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc up rep_good nopl pni monitor ssse3 lahf_lm bogomips: 3376.09 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: and the first lines of config.log are (I am sorry, I can not attach a file) $ ./configure --prefix=/home/elias/ --enable-cxx=yes --enable-gmpcompat=yes CC=gcc-4.6 CXX=g++-4.6 ## - ## ## Platform. ## ## - ## hostname = aeolus-lu64 uname -m = x86_64 uname -r = 3.5.0-18-generic uname -s = Linux uname -v = #29-Ubuntu SMP Fri Oct 19 10:26:51 UTC 2012 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/lib/lightdm/lightdm PATH: /usr/local/sbin PATH: /usr/local/bin -- Elias So what does $ gcc-4.6 -march=native -v -c -x c /dev/null -o /dev/null 21 | grep -w cc1 give (especially the '-m...' parameters passed to 'cc1'), in contrast to what MPIR used (shown by 'configure', the lines after 'using ABI=...) ? By the way, Ubuntu's GCC 4.6 is presumably Ubuntu's GCC 4.6.3, which is quite different to FSF's GCC 4.6.3, i.e., besides some other changes contains parts from the 4.7 branch. -leif On Thursday, November 15, 2012 4:13:40 PM UTC+1, Bill Hart wrote: Hi Elias, this might be to do with the virtual box, as we've tested on a large number of real machines and not encountered this yet. You may have to tell mpir's configure what the machine actually is by passing a --build=whatever Can you tell us what ./config.guess says on your system. Also, could you attach a copy of the config.log. Can you also attach the output of cat /proc/cpuinfo Thanks, Bill. On 15 November 2012 14:13, Elias elias.ts...@gmail.com javascript: wrote: Dear developers, when I do a make check with mpir 2.6.0, I get the following error /bin/bash: line 1: 17730 Illegal instruction (core dumped) $tst t-get_d.log-t 21 I am running lubuntu 12.10 using a virtual box in mac os lion. The compiler is gcc 4.6 Probably this causes problem in the installation of flint, but I will send another email for this. Can you please help me with this? best, -- Elias -- You received this message because you are subscribed to the Google Groups mpir-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/mpir-devel/-/YAi4NCxUpWAJ https://groups.google.com/d/msg/mpir-devel/-/YAi4NCxUpWAJ. To post to this group, send email to mpir-...@googlegroups.com javascript:. To unsubscribe from this group, send email to mpir-devel+...@googlegroups.com javascript:. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en http://groups.google.com/group/mpir-devel?hl=en. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/mpir-devel/-/MLIfpiTcmYwJ. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] problem with make check mpir 2.6.0
Elias wrote: On Thursday, November 15, 2012 5:34:33 PM UTC+1, leif wrote: So what does $ gcc-4.6 -march=native -v -c -x c /dev/null -o /dev/null 21 | grep -w cc1 /usr/lib/gcc/x86_64-linux-gnu/4.6/cc1 -quiet -v -imultilib . -imultiarch x86_64-linux-gnu /dev/null -march=corei7-avx -mno-cx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2 -mno-sse4.1 -mno-rdrnd -mno-f16c -mno-fsgsbase --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=corei7-avx -quiet -dumpbase null -auxbase-strip /dev/null -version -fstack-protector -o /tmp/ccdLHpEj.s Thanks. So GCC is pretty smart detecting the features actually supported... (Note the many '-mno-...' parameters.) I guess MPIR just passed '-march=corei7-avx' (Sandy Bridge), which led GCC to emitting instructions supported by the CPU, but not VirtualBox (or whatever virtual machine you're using). FWIW, /proc/cpuinfo seems to correctly reflect what the VM is capable of: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc up rep_good nopl pni monitor ssse3 lahf_lm -leif give (especially the '-m...' parameters passed to 'cc1'), in contrast to what MPIR used (shown by 'configure', the lines after 'using ABI=...) ? By the way, Ubuntu's GCC 4.6 is presumably Ubuntu's GCC 4.6.3, which is quite different to FSF's GCC 4.6.3, i.e., besides some other changes contains parts from the 4.7 branch. This is a very good point. I didn't notice. -- Elias -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MPIR tuning -- help needed
Bill Hart wrote:
OK, I've added the parameters from JP. I'll wait until Leif supplies
us with the AMD Bobcat timings and that will probably have to do.
On the way... Some figures vary quite a lot (despite the machine being
otherwise idle), so I'm running tuneup a couple more times.
The one major thing we don't have is ARM tuning values. But we just
don't seem to have any ARMs online anywhere at the moment (except in
our pockets).
I asked Julien Puydt, and he gracefully contributed the attached ones
for ARM/Linux, GCC 4.6.? (ARM v7l, cf. attached cpuinfo).
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS: 1987.37
processor : 1
BogoMIPS: 1987.37
Features: swp half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x1
CPU part: 0xc09
CPU revision: 0
Hardware: Toshiba AC100 / Dynabook AZ
Revision:
Serial :
/* Generated by tuneup.c, 2012-10-25, gcc 4.6 */
#define MUL_KARATSUBA_THRESHOLD 22
#define MUL_TOOM3_THRESHOLD 121
#define MUL_TOOM4_THRESHOLD 180
#define MUL_TOOM8H_THRESHOLD274
#define SQR_BASECASE_THRESHOLD7
#define SQR_KARATSUBA_THRESHOLD 44
#define SQR_TOOM3_THRESHOLD 145
#define SQR_TOOM4_THRESHOLD 375
#define SQR_TOOM8_THRESHOLD 375
#define POWM_THRESHOLD 190
#define HGCD_THRESHOLD 61
#define GCD_DC_THRESHOLD 1737
#define GCDEXT_DC_THRESHOLD1240
#define JACOBI_BASE_METHOD1
#define DIVREM_1_NORM_THRESHOLD 0 /* preinv always */
#define DIVREM_1_UNNORM_THRESHOLD 0 /* always */
#define MOD_1_NORM_THRESHOLD 0 /* always */
#define MOD_1_UNNORM_THRESHOLD0 /* always */
#define USE_PREINV_DIVREM_1 1 /* preinv always */
#define USE_PREINV_MOD_1 1 /* preinv always */
#define DIVREM_2_THRESHOLD0 /* preinv always */
#define DIVEXACT_1_THRESHOLD 0 /* always */
#define MODEXACT_1_ODD_THRESHOLD 0 /* always */
#define MOD_1_1_THRESHOLD 5
#define MOD_1_2_THRESHOLD10
#define MOD_1_3_THRESHOLD34
#define DIVREM_HENSEL_QR_1_THRESHOLD 11
#define RSH_DIVREM_HENSEL_QR_1_THRESHOLD996
#define DIVREM_EUCLID_HENSEL_THRESHOLD 8
#define ROOTREM_THRESHOLD 6
#define GET_STR_DC_THRESHOLD 10
#define GET_STR_PRECOMPUTE_THRESHOLD 19
#define SET_STR_DC_THRESHOLD 4183
#define SET_STR_PRECOMPUTE_THRESHOLD 30759
#define MUL_FFT_FULL_THRESHOLD 3776
#define SQR_FFT_FULL_THRESHOLD 6912
#define MULLOW_BASECASE_THRESHOLD 0 /* always */
#define MULLOW_DC_THRESHOLD 53
#define MULLOW_MUL_THRESHOLD 4437
#define MULHIGH_BASECASE_THRESHOLD0 /* always */
#define MULHIGH_DC_THRESHOLD 54
#define MULHIGH_MUL_THRESHOLD 9970
#define MULMOD_2EXPM1_THRESHOLD 26
#define FAC_UI_THRESHOLD 1203
#define DC_DIV_QR_THRESHOLD 358
#define DC_DIVAPPR_Q_N_THRESHOLD229
#define INV_DIV_QR_THRESHOLD 1187
#define INV_DIVAPPR_Q_N_THRESHOLD 229
#define DC_DIV_Q_THRESHOLD 263
#define INV_DIV_Q_THRESHOLD4318
#define DC_DIVAPPR_Q_THRESHOLD 229
#define INV_DIVAPPR_Q_THRESHOLD 10153
#define DC_BDIV_QR_THRESHOLD358
#define DC_BDIV_Q_THRESHOLD 112
/* fft_tuning -- autogenerated by tune-fft */
#define FFT_TAB \
{ { 3, 2 }, { 3, 2 }, { 2, 1 }, { 1, 0 }, { 1, 0 } }
#define MULMOD_TAB \
{ 4, 3, 3, 3, 3, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1 }
#define FFT_N_NUM 15
#define FFT_MULMOD_2EXPP1_CUTOFF 128
/* Tuneup completed successfully, took 1044 seconds */
Re: [mpir-devel] Re: MPIR tuning -- help needed
Bill Hart wrote: On 25 October 2012 21:34, leif not.rea...@online.de wrote: Bill Hart wrote: OK, I've added the parameters from JP. I'll wait until Leif supplies us with the AMD Bobcat timings and that will probably have to do. On the way... Some figures vary quite a lot (despite the machine being otherwise idle), so I'm running tuneup a couple more times. That's ok, some of the crossovers are pretty wide. Ok, I took the dominant or approx. average ones; see below for those that vary broadly. Have fun, -leif #define DIVREM_EUCLID_HENSEL_THRESHOLD 8 #define DIVREM_EUCLID_HENSEL_THRESHOLD 8 #define DIVREM_EUCLID_HENSEL_THRESHOLD 15 #define DIVREM_EUCLID_HENSEL_THRESHOLD 17 #define DIVREM_EUCLID_HENSEL_THRESHOLD 18 #define DIVREM_EUCLID_HENSEL_THRESHOLD 18 #define DIVREM_EUCLID_HENSEL_THRESHOLD 21 #define DIVREM_EUCLID_HENSEL_THRESHOLD 23 #define DIVREM_EUCLID_HENSEL_THRESHOLD 23 #define DIVREM_EUCLID_HENSEL_THRESHOLD 75 #define DIVREM_EUCLID_HENSEL_THRESHOLD 89 #define DIVREM_EUCLID_HENSEL_THRESHOLD 91 #define DIVREM_EUCLID_HENSEL_THRESHOLD141 #define DIVREM_EUCLID_HENSEL_THRESHOLD170 #define DIVREM_EUCLID_HENSEL_THRESHOLD208 #define HGCD_THRESHOLD 30 #define HGCD_THRESHOLD 30 #define HGCD_THRESHOLD 30 #define HGCD_THRESHOLD 30 #define HGCD_THRESHOLD 30 #define HGCD_THRESHOLD 31 #define HGCD_THRESHOLD 35 #define HGCD_THRESHOLD 37 #define HGCD_THRESHOLD 52 #define HGCD_THRESHOLD 54 #define HGCD_THRESHOLD 92 #define HGCD_THRESHOLD 109 #define HGCD_THRESHOLD 110 #define HGCD_THRESHOLD 318 #define HGCD_THRESHOLD 422 #define SET_STR_PRECOMPUTE_THRESHOLD214 #define SET_STR_PRECOMPUTE_THRESHOLD214 #define SET_STR_PRECOMPUTE_THRESHOLD222 #define SET_STR_PRECOMPUTE_THRESHOLD230 #define SET_STR_PRECOMPUTE_THRESHOLD240 #define SET_STR_PRECOMPUTE_THRESHOLD382 #define SET_STR_PRECOMPUTE_THRESHOLD399 #define SET_STR_PRECOMPUTE_THRESHOLD411 #define SET_STR_PRECOMPUTE_THRESHOLD427 #define SET_STR_PRECOMPUTE_THRESHOLD499 #define SET_STR_PRECOMPUTE_THRESHOLD671 #define SET_STR_PRECOMPUTE_THRESHOLD716 #define SET_STR_PRECOMPUTE_THRESHOLD752 #define SET_STR_PRECOMPUTE_THRESHOLD828 #define SET_STR_PRECOMPUTE_THRESHOLD984 bobcat-unknown-linux-gnu (btver1) -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. processor : 0 vendor_id : AuthenticAMD cpu family : 20 model : 2 model name : AMD E-450 APU with Radeon(tm) HD Graphics stepping: 0 cpu MHz : 1650.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor ssse3 cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch ibs skinit wdt arat npt lbrv svm_lock nrip_save pausefilter bogomips: 3292.78 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate processor : 1 vendor_id : AuthenticAMD cpu family : 20 model : 2 model name : AMD E-450 APU with Radeon(tm) HD Graphics stepping: 0 cpu MHz : 1650.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 6 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni monitor ssse3 cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch ibs skinit wdt arat npt lbrv svm_lock nrip_save pausefilter bogomips: 3292.91 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits
Re: [mpir-devel] MPIR tuning -- help needed
Bill Hart wrote: Hi all, I have run make check and make tune on the following arches: x86_64/k102 - fermat x86_64/nehalem - jeff gilchrist x86_64/k8 - flavius x86/pentium4/sse2 - cicero x86_64/netburst - sextus (tune crashed) x86_64/core2 - eno sparc64 - mark (tune crashed) (ultrasparc3) sparc32 - mark (ultrasparc3) x86_64/penryn - sage.math x86_64/k10 - gcc16 x86_64/atom - gcc46 mips64 - gcc49 (tuning failed) ppc64 - (tuning failed) (IBM power7) However, I still have no tuning values for alpha, ARM, AMD bobcat, Intel sandybrige, mips32, ppc32. If anyone has access to such machines, please let me know. I can submit tuning parameters for an AMD E-450 (btver1, 512 KB L2 per core; Linux, GCC 4.6.3 and/or GCC 4.7.0) tomorrow. -leif We have generic tuning values for the fft, but it is better to have properly tuned values. Brian, you should be able to pull tuning values for Windows from the *nix values now. I'm afraid the only x86 amongst them is the x86/pentium4/sse2 machine. But there are plenty of x86_64s. The two crashed tuning runs are due to the fft tuning crashing. I don't know what caused this, but it isn't urgent to fix it. We expected tuning to fail on lots of platforms. I constructed the best set of values I could from the tuning values that we were able to get. The other tuning failures are known failures which have never been fixed. The default values will have to do on these machines. Bill. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
Bill Hart wrote: Another problem is in the test functions for the ux/sx functions, we use %lld in the format specifier for an intmax_t. This is only valid if intmax_t is actually a long long int, which it is not on some *nix platforms (ia64 for example). C99 introduced a new format specifier (which I forgot already) for intmax_t. Of course this is only supported by C99 compilers. I hope MSVC is C99 compliant enough to have gotten this right, otherwise we have a lot of fiddling around to do. It doesn't really specify new format letters AFAIK, but inttypes.h, which defines macros for (portably) printing and scanning the types defined in stdint.h, e.g. PRIu64 and SCNu64, regardless of whether uint64_t expands to 'unsigned long' (%lu) or 'unsigned long long' (%llu); one can for example use printf(%20PRIu64\n, (uint64_t)foo); // mind the % and quoting For printing [u]intmax_t, the macros are PRIdMAX, PRIiMAX, PRIoMAX (octal), PRIuMAX, PRIxMAX and PRIXMAX (hexadecimal, lower and upper case, respectively). -leif On 12 October 2012 20:34, Bill Hart goodwillh...@googlemail.com wrote: That actually won't work. For C++ we must include stdint.h and not limits.h. Bill. On 12 October 2012 20:32, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 8:30 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released Oh no it doesn't, I made a mistake. It has #if defined( _STDINT_H ) || defined ( _STDINT_H_ ) || defined ( _STDINT ) I was about to query this :-) We will need to include limits.h to pick up LLONG_MAX Brian -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
Brian Gladman wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 9:15 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released I believe these only get defined if you first define some macro. On 12 October 2012 21:13, leif not.rea...@online.de wrote: Bill Hart wrote: Another problem is in the test functions for the ux/sx functions, we use %lld in the format specifier for an intmax_t. This is only valid if intmax_t is actually a long long int, which it is not on some *nix platforms (ia64 for example). C99 introduced a new format specifier (which I forgot already) for intmax_t. Of course this is only supported by C99 compilers. I hope MSVC is C99 compliant enough to have gotten this right, otherwise we have a lot of fiddling around to do. It doesn't really specify new format letters AFAIK, but inttypes.h, which defines macros for (portably) printing and scanning the types defined in stdint.h, e.g. PRIu64 and SCNu64, regardless of whether uint64_t expands to 'unsigned long' (%lu) or 'unsigned long long' (%llu); one can for example use printf(%20PRIu64\n, (uint64_t)foo); // mind the % and quoting For printing [u]intmax_t, the macros are PRIdMAX, PRIiMAX, PRIoMAX (octal), PRIuMAX, PRIxMAX and PRIXMAX (hexadecimal, lower and upper case, respectively). -leif However, inttypes.h is not available on Windows. Going back to stdint.h, I think the assumption is that this needs to be included by the user before the mpirxx.h include so we should not include it in mpirxx.h On Windows the C++ header for LLONG_MAX is climits - I am surprised that this doesn't exist on *nix. Well, it does (or should). -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
Bill Hart wrote: On 12 October 2012 23:19, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 11:11 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released On 12 October 2012 23:06, Brian Gladman b...@gladman.plus.com wrote: -Original Message- From: Bill Hart Sent: Friday, October 12, 2012 10:58 PM To: mpir-devel@googlegroups.com Subject: Re: [mpir-devel] MPIR 2.6.0 alpha1 released [snip] There are a couple more instances of _MSC_VER guards in mpirxx.h. Did you only mean to change two of them? No, I meant to do all of them - I'll go through this again. OK, I believe there are two more instances. By the way, I have been going through the tests that use config.h and I have done about ten of them so far and I haven't found even one that actually needs config.h on Windows (i.e the test compiles and runs when this include is omitted). Well, we can try removing them and adding them back in if they are actually needed. Probably they were only added for this specific problem, which we've now resolved by simply excluding the relevant code on Linux. = Ok, I'll go through them and take them out if they are not needed on Windows. You can then test is this breaks the tests on *nix. On the print format issue for mp_limb_t, mp_limb_unsigned_t, intmax_t and uintmax_t, mp_bitcnt_t, ... should we add format specifiers (or macros) in gmp_h.in where these types are defined? Yeah, but I think the people who came up with this new feature of C compilers sat around a table late one night drinking vodka and decided to implement the most useless and most difficult to rectify feature their evil brains could concoct. So I am not convinced there are portable macros which actually work everywhere. So we are probably wasting our time trying. Well, the crude macros (or what they expand to) are not a feature of the compiler, but the implementation of the printf() and scanf() family of functions, i.e., again the C library. (Although e.g. GCC actually interprets format strings to eventually generate warnings.) And while you cannot use sizeof() in preprocessor conditionals, you could of course do things like printf(sizeof(foo)==sizeof(long)?%ld\n:%lld\n, foo); (or dynamically create/modify some format string variable in the code and pass that). -leif P.S.: For the stdint.h / inttypes.h issue, you could at least include / use them if __STDC_VERSION__ = 199901L (and __STDC_HOSTED__ is defined ;-) ). IIRC MPIR compiles its tests with '-std=c99' or '-std=gnu99' and the like if possible anyway. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
Bill Hart wrote: On 7 October 2012 04:10, leif not.rea...@online.de wrote: With GCC 4.7.0 (and CFLAGS=-O0 -finline-functions -fschedule-insns, since this version is severely broken on Itanium) I get: libtool: link: ranlib .libs/libtests.a libtool: link: ( cd .libs rm -f libtests.la ln -s ../libtests.la libtests.la ) gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../mpir-2.6.0-alpha1/tests -I.. -I../../mpir-2.6.0-alpha1-O0 -finline-functions -fschedule-insns -c ../../mpir-2.6.0-alpha1/tests/t-bswap.c /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -O0 -finline-functions -fschedule-insns -o t-bswap t-bswap.o libtests.la ../libmpir.la libtool: link: gcc -std=gnu99 -O0 -finline-functions -fschedule-insns -o .libs/t-bswap t-bswap.o ./.libs/libtests.a /home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/.libs/libmpir.so -lm ../.libs/libmpir.so /home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/.libs/libmpir.so: undefined reference to `mpn_addmod_2expp1_1' collect2: error: ld returned 1 exit status make[4]: *** [t-bswap] Error 1 make[4]: Leaving directory `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/tests' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0' make: *** [check] Error 2 It's pointless trying to build anything with gcc 4.7.0. It's a totally useless version of the compiler. :-) Birthday edition... Having said that, the function in question is a GMP_EXTERN_INLINE function defined in gmp-impl.h. Unfortunately, GMP_EXTERN_INLINE is not defined in gmp-impl.h. I'll move the definition into gmp-h.in where it is actually defined. I've no idea why this worked everywhere else but not on this system. It could still be a compiler bug of course. I haven't looked at this at all, but I'd guess it's related to the optimization level, i.e., there usually don't remain any references to that function. Btw, invalid options to 'configure' (e.g. '--enable-gmp-compat' or '--enable-foo') are silently ignored, even with '-v'; probably just some (newer) autotools feature... I think we possibly do this deliberately as some options need to be passed to yasm's configure. The recursive 'configure' is already called with '--disable-option-checking' (or what it is called). If you can give me a list of all possible invalid options users will type, I'll make sure they are excluded. (Just joking.) No space left on device... :-/ But you should certainly test for '--enable-gmpcombat'. -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MPIR 2.6.0 alpha1 released
Bill Hart wrote: The second issue is almost certainly a bug. The first looks like it could be, due to the presence of intmax_t in the output. But the cxx has never built on some machines we have access to due to broken compilers. I'll look into it. While I do get the same results with GCC 4.1.2 and MPIR 2.5.2 [first / C++ issue], the linker error with GCC 4.7.0 [second issue] is a regression w.r.t. 2.5.2, i.e., MPIR 2.5.2's testsuite builds and passes all tests with GCC 4.7.0 (Linux IA64 / SLES 10 Itanium). Haven't investigated further; someone^TM should install GCC 4.7.2 (or 4.7.1, which fixed the brokenness on Itanium)... ;-) -leif I forgot to mention that we need to run make tune on each arch we have access to and put the resulting output in the correct gmp-mparam.h file in the relevant mpn directory. Of course without svn access (we are switching to git soon I promise), the best way is to just post the output to the list along with the output from config.guess and let one of us commit it. Bill. On Sunday, 7 October 2012, leif wrote: Bill Hart wrote: Hi all, It is with pleasure that we release MPIR 2.6.0 alpha1. The source and documentation can be downloaded at http://mpir.org/ This release contains a new FFT, support for intmax_t integers, a Python build generator and various bug fixes. The alpha version has been tested on only a few architectures at this point. We appreciate any and all build/bug reports. Once testing is complete, the status will be upgraded to beta or perhaps final. FWIW, I've successfully built MPIR 2.6.0-alpha1 (with '--enable-cxx' and '--enable-gmpcompat') and run 'make check' on the following platforms: Linux PPC64 (SLES 11, POWER7), GCC 4.3.4 (without C++ support) Linux PPC64 (SLES 11, POWER7), GCC 4.6.3 Solaris SPARC (SunOS 5.10, UltraSPARC III), GCC 4.7.0, ABI=32 Solaris SPARC (SunOS 5.10, UltraSPARC III), GCC 4.7.0, ABI=64 I didn't try to (re)build/test anything using GMP/MPIR though. On Linux IA64 (SLES 10, Itanium) in contrast, I got the following failures: With the (fairly old) native GCC 4.1.2, building the testsuite fails: make[4]: Entering directory `/home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.1.2/__tests/cxx' g++ -DHAVE_CONFIG_H -I. -I../../../mpir-2.6.0-alpha1/__tests/cxx -I../.. -I../../../mpir-2.6.0-alpha1 -I../../../mpir-2.6.0-alpha1/__tests-O2 -c -o t-assign.o ../../../mpir-2.6.0-alpha1/__tests/cxx/t-assign.cc ../../../mpir-2.6.0-alpha1/__mpirxx.h:1587: error: ‘__gmp_expr__mpz_struct [1], __mpz_struct [1]::__gmp_expr(intmax_t)’ cannot be overloaded ../../../mpir-2.6.0-alpha1/__mpirxx.h:1578: error: with ‘__gmp_expr__mpz_struct [1], __mpz_struct [1]::__gmp_expr(long int)’ ../../../mpir-2.6.0-alpha1/__mpirxx.h:1588: error: ‘__gmp_expr__mpz_struct [1], __mpz_struct [1]::__gmp_expr(uintmax_t)’ cannot be overloaded ../../../mpir-2.6.0-alpha1/__mpirxx.h:1579: error: with ‘__gmp_expr__mpz_struct [1], __mpz_struct [1]::__gmp_expr(long unsigned int)’ ../../../mpir-2.6.0-alpha1/__mpirxx.h:1656: error: ‘__gmp_expr__mpz_struct [1], __mpz_struct [1] __gmp_expr__mpz_struct [1], __mpz_struct [1]::operator=(intmax_t)’ cannot be overloaded ../../../mpir-2.6.0-alpha1/__mpirxx.h:1647: error: with ‘__gmp_expr__mpz_struct [1], __mpz_struct [1] __gmp_expr__mpz_struct [1], __mpz_struct [1]::operator=(long int)’ ../../../mpir-2.6.0-alpha1/__mpirxx.h:1657: error: ‘__gmp_expr__mpz_struct [1], __mpz_struct [1] __gmp_expr__mpz_struct [1], __mpz_struct [1]::operator=(uintmax_t)’ cannot be overloaded ../../../mpir-2.6.0-alpha1/__mpirxx.h:1648: error: with ‘__gmp_expr__mpz_struct [1], __mpz_struct [1] __gmp_expr__mpz_struct [1], __mpz_struct [1]::operator=(long unsigned int)’ make[4]: *** [t-assign.o] Error 1 make[4]: Leaving directory `/home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.1.2/__tests/cxx' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.1.2/__tests/cxx' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.1.2/__tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/leif/src/mpir-2.6.0-__alpha1-build.iras-gcc-4.1.2' make: *** [check] Error 2 $ gcc -v Using built-in specs. Target: ia64-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,__fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/__include/c++/4.1.2 --enable-ssp --disable
Re: [mpir-devel] MPIR 2.6.0 alpha1 released
Bill Hart wrote: Hi all, It is with pleasure that we release MPIR 2.6.0 alpha1. The source and documentation can be downloaded at http://mpir.org/ This release contains a new FFT, support for intmax_t integers, a Python build generator and various bug fixes. The alpha version has been tested on only a few architectures at this point. We appreciate any and all build/bug reports. Once testing is complete, the status will be upgraded to beta or perhaps final. FWIW, I've successfully built MPIR 2.6.0-alpha1 (with '--enable-cxx' and '--enable-gmpcompat') and run 'make check' on the following platforms: Linux PPC64 (SLES 11, POWER7), GCC 4.3.4 (without C++ support) Linux PPC64 (SLES 11, POWER7), GCC 4.6.3 Solaris SPARC (SunOS 5.10, UltraSPARC III), GCC 4.7.0, ABI=32 Solaris SPARC (SunOS 5.10, UltraSPARC III), GCC 4.7.0, ABI=64 I didn't try to (re)build/test anything using GMP/MPIR though. On Linux IA64 (SLES 10, Itanium) in contrast, I got the following failures: With the (fairly old) native GCC 4.1.2, building the testsuite fails: make[4]: Entering directory `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.1.2/tests/cxx' g++ -DHAVE_CONFIG_H -I. -I../../../mpir-2.6.0-alpha1/tests/cxx -I../.. -I../../../mpir-2.6.0-alpha1 -I../../../mpir-2.6.0-alpha1/tests-O2 -c -o t-assign.o ../../../mpir-2.6.0-alpha1/tests/cxx/t-assign.cc ../../../mpir-2.6.0-alpha1/mpirxx.h:1587: error: ‘__gmp_expr__mpz_struct [1], __mpz_struct [1]::__gmp_expr(intmax_t)’ cannot be overloaded ../../../mpir-2.6.0-alpha1/mpirxx.h:1578: error: with ‘__gmp_expr__mpz_struct [1], __mpz_struct [1]::__gmp_expr(long int)’ ../../../mpir-2.6.0-alpha1/mpirxx.h:1588: error: ‘__gmp_expr__mpz_struct [1], __mpz_struct [1]::__gmp_expr(uintmax_t)’ cannot be overloaded ../../../mpir-2.6.0-alpha1/mpirxx.h:1579: error: with ‘__gmp_expr__mpz_struct [1], __mpz_struct [1]::__gmp_expr(long unsigned int)’ ../../../mpir-2.6.0-alpha1/mpirxx.h:1656: error: ‘__gmp_expr__mpz_struct [1], __mpz_struct [1] __gmp_expr__mpz_struct [1], __mpz_struct [1]::operator=(intmax_t)’ cannot be overloaded ../../../mpir-2.6.0-alpha1/mpirxx.h:1647: error: with ‘__gmp_expr__mpz_struct [1], __mpz_struct [1] __gmp_expr__mpz_struct [1], __mpz_struct [1]::operator=(long int)’ ../../../mpir-2.6.0-alpha1/mpirxx.h:1657: error: ‘__gmp_expr__mpz_struct [1], __mpz_struct [1] __gmp_expr__mpz_struct [1], __mpz_struct [1]::operator=(uintmax_t)’ cannot be overloaded ../../../mpir-2.6.0-alpha1/mpirxx.h:1648: error: with ‘__gmp_expr__mpz_struct [1], __mpz_struct [1] __gmp_expr__mpz_struct [1], __mpz_struct [1]::operator=(long unsigned int)’ make[4]: *** [t-assign.o] Error 1 make[4]: Leaving directory `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.1.2/tests/cxx' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.1.2/tests/cxx' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.1.2/tests' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.1.2' make: *** [check] Error 2 $ gcc -v Using built-in specs. Target: ia64-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2 --enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --program-suffix= --enable-version-specific-runtime-libs --with-system-libunwind --host=ia64-suse-linux Thread model: posix gcc version 4.1.2 20070115 (prerelease) (SUSE Linux) (No idea whether any recent version of MPIR does build with that version of GCC.) Without '--enable-cxx', the testsuite builds and passes. With GCC 4.7.0 (and CFLAGS=-O0 -finline-functions -fschedule-insns, since this version is severely broken on Itanium) I get: libtool: link: ranlib .libs/libtests.a libtool: link: ( cd .libs rm -f libtests.la ln -s ../libtests.la libtests.la ) gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../mpir-2.6.0-alpha1/tests -I.. -I../../mpir-2.6.0-alpha1-O0 -finline-functions -fschedule-insns -c ../../mpir-2.6.0-alpha1/tests/t-bswap.c /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -O0 -finline-functions -fschedule-insns -o t-bswap t-bswap.o libtests.la ../libmpir.la libtool: link: gcc -std=gnu99 -O0 -finline-functions -fschedule-insns -o .libs/t-bswap t-bswap.o ./.libs/libtests.a /home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/.libs/libmpir.so -lm ../.libs/libmpir.so /home/leif/src/mpir-2.6.0-alpha1-build.iras-gcc-4.7.0/.libs/libmpir.so: undefined reference to `mpn_addmod_2expp1_1' collect2: error: ld returned 1 exit status make[4
Re: [mpir-devel] MPIR and gcc-4.3.2
Bill Hart wrote: Sorry, I meant it was the rootrem code that fails. http://trac.mpir.org/mpir_trac/ticket/291 (I believe the information about it being a misexpansion of MPN_ZERO is incorrect -- it was much more fundamental, affecting simple for loops) http://us.generation-nt.com/answer/bug-524472-gcc-4-3-gcc-4-3-2-miscompiles-gmp-4-3-0-help-168491181.html Ad-free: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524472 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36765 Note that apparently *FSF* GCC 4.3.2 isn't affected, it's just Debian's. -leif On 9 May 2012 11:18, Bill Hartgoodwillh...@googlemail.com wrote: The test that often fails is the (extended) gcd one. However, it is unsafe to run MPIR with this gcc unpatched, even if the test code passes, as wrong answers may be returned. It's a long time ago, but as I recall, certain for loops in MPIR compiled incorrectly. This wasn't a preparser problem, so all attempts to replace the code with something alternative that worked, failed. Of course it would also have meant analysing and rewriting whole swathes of MPIR even if we did find a way to work around it. We didn't add a test for this to MPIR's test suite. But I have no idea why the existing test suite doesn't fail for you. It certainly did on the x86_64 machines I tried. As noted, the problem also affects GMP. Bill. On 9 May 2012 09:14, Jeroen Demeyerjdeme...@cage.ugent.be wrote: On 2012-05-09 10:05, Jason Moxham wrote: So what's the motivation for refusing to build MPIR with gcc-4.3.2? The configure script essentially just says it's broken without specifying how or why. I have built MPIR with gcc-4.3.2 on a GNU/Linux x86_64 system with -march=nocona and built gcc with that MPIR and I had no problems at all. - gcc-4.3.2 fails MPIR's make check on x64 , I think it's the reuse test , I suppose we should write a proper test so patched gcc's will work , but I'm not at all sure what part of gcc is broken as we can't use the reuse test itself as it needs MPIR to be built first. Note GMP is also broken on gcc-4.3.2 Sorry, I should have mentioned that I did run the testsuite with gcc-4.3.2 and all tests passed. So if there really is a problem with gcc-4.3.2, the testsuite of MPIR-2.4.0 doesn't catch it. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] [BUG] Insufficient quoting for m4 in .asm files
Jeroen Demeyer wrote: Some .asm files which are processed by m4 have something like define(OPERATION_popcount,1) This should be define(`OPERATION_popcount',1) $ grep '^[ \t]*define[ \t]*([ \t]*[a-zA-Z_]' `find mpir-2.4.0/ -name \*.asm` | wc -l 448 The problem is that m4 might be called with m4 -DOPERATION_popcount popcount.asm Then define(OPERATION_popcount,1) expands to define(,1). *Some* versions of m4 bail out with an error on this. More context: http://trac.sagemath.org/sage_trac/ticket/11616#comment:36 -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR-2.5.1 doesn't compile with GCC-4.7.0 on ia64
Bill Hart wrote: This error seems to occur when compiling the .c file. Yet the complaint is about the generated assembly. My first reaction is that this is a compiler bug and should be reported to the GCC folks. It does seem to have detected the processor correctly. Unfortunately this file is not in GMP. However, one should be able to verify that it is a compiler issue by compiling a previous version of MPIR that contained this file. As we know MPIR compiled fine with previous GCC releases on that platform, this should give us good confidence that it is indeed the compiler. Bill. On 28 March 2012 08:17, Jeroen Demeyerjdeme...@cage.ugent.be wrote: On ia64 systems, MPIR-2.5.1 fails to compile with GCC-4.7.0: $ uname -a Linux cleo 2.6.18-128.1.1.el5 #1 SMP Mon Jan 26 13:57:09 EST 2009 ia64 ia64 ia64 GNU/Linux $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7.0/ia64-Linux-rhel/libexec/gcc/ia64-unknown-linux-gnu/4.7.0/lto-wrapper Target: ia64-unknown-linux-gnu Configured with: /usr/local/gcc-4.7.0/src/gcc-4.7.0/configure --enable-languages=c,c++,fortran --with-gnu-as --with-as=/usr/local/binutils-2.22/ia64-Linux-rhel-gcc-4.6.2/bin/as --with-gnu-ld --with-ld=/usr/local/binutils-2.22/ia64-Linux-rhel-gcc-4.6.2/bin/ld --with-gmp=/usr/local/mpir-2.5.1/ia64-Linux-rhel-gcc-4.6.2 So it's clearly not related to the /MPIR/ version. -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Fwd: [sage-devel] Re: Upgrading the optional GMP spkg
Jason wrote: I added app tests for mpfr-3.1.0 mpfi-1.5.1 ecm-6.4.1 flint-2.3 pari-2.5.1 [Apparently Jeroen missed this.] and the first missing functions are ../../../mpfr-3.1.0/src/mulders.c: In function 'mpfr_divhigh_n_basecase': ../../../mpfr-3.1.0/src/mulders.c:208:3: error: 'gmp_pi1_t' undeclared (first use in this function) ../../../mpfr-3.1.0/src/mulders.c:208:3: note: each undeclared identifier is reported only once for each function it appears in ../../../mpfr-3.1.0/src/mulders.c:208:14: error: expected ';' before 'dinv2' ../../../mpfr-3.1.0/src/mulders.c:229:3: warning: implicit declaration of function 'invert_pi1' ../../../mpfr-3.1.0/src/mulders.c:229:15: error: 'dinv2' undeclared (first use in this function) ../../../mpfr-3.1.0/src/mulders.c:244:9: warning: implicit declaration of function 'udiv_qr_3by2' make[2]: *** [mulders.lo] Error 1 I'll add the new undocumented functions this weekend to the svn for a mpir-2.5.2 release in the next week or so Note that MPFR 3.1.0 builds and works well with (still) MPIR 2.1.3 in Sage, so these types and functions must have been removed from MPIR at some point, unless I'm missing something... -leif and also tests for the current stable GAP and the development version of GAP --- We currently test against mpfr-3.0.1.tar.bz2 mpfi-1.5.tar.bz2 mpc-0.9.tar.gz ecm-6.3.tar.gz flint-2.1.tgz pari-2.3.5.tar.gz on all the usual test machines. I can easily add gap and any other smallish packages(sage itself is too big) and/or versions. Jason --- Probably GAP uses some of the GMP internals. As far as I know, we don't test MPIR against GAP. It sounds like we should. Bill. On 14 March 2012 02:55, William Steinwst...@gmail.com wrote: Hi MPIR devs Do any of you know what Dima is alluding to below? -- Forwarded message -- From: Dima Pasechnikdimp...@gmail.com Date: Tue, Mar 13, 2012 at 11:18 AM Subject: [sage-devel] Re: Upgrading the optional GMP spkg To: sage-de...@googlegroups.com On Tuesday, 13 March 2012 21:30:07 UTC+8, Simon King wrote: Hi! I had problems with the optional gmp-4.2.1 spkg. After some half- succeeding attempts to fix it, I tried to upgrade the spkg to the latest upstream code: It works like a charm (i.e., builds and passes self-tests)! If someone is interested: #12661 provides a new gmp-5.0.4.spkg (intended to be optional, of course) and needs review. that's the version of GMP used by GAP 4.5 (they are moving towards using an external longnums package), and I know they recently were working quite a bit with GMP people to get in the right patches. I wish GAP worked with MPIR, but the latter does not provide all the GMP calls used by GAP. It would be good if these were added... Dima The old spkg had a lot of patches. So far, the new applies none of them - on openSuse, the unpatched code passes tests. However, I'd be glad if the patch authors could check whether the fixes (some of them addressing platform specific issues) all made it upstream. According to the old spkg's SPKG.txt, it is needed to upgrade the optional polymake spkg if gmp is upgraded. I haven't tried it. Best regards, Simon -- To post to this group, send an email to sage-de...@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Fwd: [sage-devel] Re: Upgrading the optional GMP spkg
Bill Hart wrote:
On 16 March 2012 09:18, leifnot.rea...@online.de wrote:
Jason wrote:
and the first missing functions are
../../../mpfr-3.1.0/src/mulders.c: In function 'mpfr_divhigh_n_basecase':
../../../mpfr-3.1.0/src/mulders.c:208:3: error: 'gmp_pi1_t' undeclared
(first use in this function)
../../../mpfr-3.1.0/src/mulders.c:208:3: note: each undeclared identifier
is reported only once for each function it appears in
../../../mpfr-3.1.0/src/mulders.c:208:14: error: expected ';' before
'dinv2'
../../../mpfr-3.1.0/src/mulders.c:229:3: warning: implicit declaration of
function 'invert_pi1'
../../../mpfr-3.1.0/src/mulders.c:229:15: error: 'dinv2' undeclared (first
use in this function)
../../../mpfr-3.1.0/src/mulders.c:244:9: warning: implicit declaration of
function 'udiv_qr_3by2'
make[2]: *** [mulders.lo] Error 1
I'll add the new undocumented functions this weekend to the svn for a
mpir-2.5.2 release in the next week or so
Note that MPFR 3.1.0 builds and works well with (still) MPIR 2.1.3 in Sage,
so these types and functions must have been removed from MPIR at some point,
unless I'm missing something...
gmp_pi1_t was not defined in MPIR 2.1.3. Perhaps someone made a patch
in Sage to fix this.
Nope, apparently upstream did. There are currently 8 bugs with patches
mentioned (see http://www.mpfr.org/mpfr-current/#fixed), but none of
them is related to this, so maybe they /silently/ changed the tarball,
or *when* and where did Jason get his one from?
In Sage (and in the current upstream tarball) we [already] have:
static mp_limb_t
mpfr_divhigh_n_basecase (mpfr_limb_ptr qp, mpfr_limb_ptr np,
mpfr_limb_srcptr dp, mp_size_t n)
{
mp_limb_t qh, d1, d0, dinv, q2, q1, q0;
mpfr_pi1_t dinv2;
...
-leif
This type is used for functions that take a precomputed inverse in
GMP. We have similar in MPIR, but the name is not the same.
The MPFR people have been doing a great job of checking MPFR is
compatible with MPIR, so I'm not sure how this has slipped through.
Anyhow, it's easy to fix.
Bill.
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] mpz_get_str encoding
Bob Smith wrote:
I'm puzzled by the description of this function which says that the base
may vary from 2..36 and -2..-36, but then goes on to describe the
allowed chars in the string for bases 37..62.
Also, I see that you use the same odd rules as does GMP for different
bases. That is,
BasesAllowed in String
-
2..360..9a..z
37..620..9A..Za..z
-2..-360..9A..Z
-37..-62unspecified
Can anyone explain why not use one sequence for all bases (other than
that's the way GMP did it)? If the latter explanation, does anyone know
why GMP did it that way?
I guess that's simply for historical reasons. (And MPIR wanted to stay
compatible with GMP.)
First, only bases up to 36 were supported, and using lower case letters
was considered more convenient.
Later, bases up to 62 were added, and the developers didn't want to
break backwards compatibility.
One could have used 0..9a..zA..Z for these, but then
ord(d1)ord(d2) = val(d1)val(d2)
would no longer hold (complicating the implementation), since for
example ord('A')=65 97=ord('a'), but val('A')=36 val('a')=10 in that
case.
But that's just my guess...
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML Email
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] mpz_get_str encoding
leif wrote:
Bob Smith wrote:
I'm puzzled by the description of this function which says that the base
may vary from 2..36 and -2..-36, but then goes on to describe the
allowed chars in the string for bases 37..62.
Also, I see that you use the same odd rules as does GMP for different
bases. That is,
BasesAllowed in String
-
2..360..9a..z
37..620..9A..Za..z
-2..-360..9A..Z
-37..-62unspecified
Can anyone explain why not use one sequence for all bases (other than
that's the way GMP did it)? If the latter explanation, does anyone know
why GMP did it that way?
I guess that's simply for historical reasons. (And MPIR wanted to stay
compatible with GMP.)
First, only bases up to 36 were supported, and using lower case letters
was considered more convenient.
Later, bases up to 62 were added, and the developers didn't want to
break backwards compatibility.
One could have used 0..9a..zA..Z for these, but then
ord(d1)ord(d2) = val(d1)val(d2)
would no longer hold (complicating the implementation), since for
example ord('A')=65 97=ord('a'), but val('A')=36 val('a')=10 in that
case.
Oh, actually the answer is simpler. The GMP documentation [1] says:
Function: int mpz_set_str (mpz_t rop, char *str, int base)
[...]
The base may vary from 2 to 62, or if base is 0, then the leading
characters are used: 0x and 0X for hexadecimal, 0b and 0B for binary, 0
for octal, or decimal otherwise.
For bases up to 36, case is ignored; upper-case and lower-case letters
have the same value. For bases 37 to 62, upper-case letter represent the
usual 10..35 while lower-case letter represent 36..61.
(The MPIR documentation of that function is identical.)
So *both* A..Z and a..z are allowed for bases up to 36, and the meaning
of a..z for bases 36 is straightforward, just as one would expect (I
think).
(The documentation of mpz_get_str() [2] is similar, except that of
course either lowercase or uppercase letters are used, or -- depending
on the base -- both at the same time, but then having different
significance.)
Btw., what documentation were you referring to? The source code doesn't
contain what you cited either.
-leif
[1]
http://gmplib.org/manual/Assigning-Integers.html#index-mpz_005fset_005fstr-262
[2]
http://gmplib.org/manual/Converting-Integers.html#index-mpz_005fget_005fstr-280
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML Email
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: C++ wrappers don't support 64-bit integers (size_t, long long int) on Win64
Bill Hart wrote: To my knowledge there are not even mpz_add_ux, mpz_mul_ux functions, etc. in the MPIR C library, let alone C++ analogues. Well, is it worth adding such? If you're using a platform which, despite its machine word width being 64 bits, doesn't support an LP64 programming environment, you have to pay the price. Obviously one can convert 64-bit long long ints to mpzs and compute with these. Adding more _ux and _sx functions would perhaps make more sense once we get long longs that are, e.g., 128 bits on a variety of platforms. Otherwise adding such functions would just break compatibility with GMP [further], i.e., programs using these functions wouldn't work with GMP on other platforms. Although it's To maintain full interface support with GMP - MPIR is a drop-in replacement for GMP, not the other way around. ;-) 2ct, -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML Email -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: C++ wrappers don't support 64-bit integers (size_t, long long int) on Win64
Bill Hart wrote: On 24 October 2011 20:31, leif not.rea...@online.de wrote: Adding more _ux and _sx functions would perhaps make more sense once we get long longs that are, e.g., 128 bits on a variety of platforms. That will never happen. 64 bits is enough for anyone. I bet the same had been said about 32-bit ints (and pointers, or an address space of 4GB) when they were introduced. 64 bits are enough, just like 32 bits are enough for IP addresses. -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML Email -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel]
Chris Saunders wrote: -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. I fully agree. -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML Email -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
[mpir-devel] Re: Race condition in parallel make install
On 1 Dez., 02:09, Jason ja...@njkfrudils.plus.com wrote: Heres the fix we have to change Makefile.am to install-data-hook: if WANT_GMPCOMPAT (rm -f $(DESTDIR)$(includedir)/gmp.h cp mpir.h $(DESTDIR)$(includedir)/gmp.h) if WANT_CXX (rm -f $(DESTDIR)$(includedir)/gmpxx.h cp mpirxx.h $(DESTDIR)$(includedir)/gmpxx.h) endif endif ignoring the line ending changes because of my email then run autoreconf on boxen I can issue a mpir-2.1.4 tomorrow as I'm testing the new 2.2.0-rc3 , this is not problem as the change is trivial and obvious. Thanks, this will obviously fix it. I must admit I was rather thinking of adding an explicit prerequisite like install-nodist_includeexecHEADERS. Btw, at least when configuring 2.1.3 with non-empty CFLAGS (which we do in Sage), we also have to add * -Wl,-z,noexecstack to clear the (erroneously set) executable stack attributes causing trouble on Fedora 14 (and other SELinux-enabled systems), * -Wa,-force_cpusubtype_ALL on MacOS X [10.5] PowerPC [G4], at least with Apple's XCode GCC 4.2.1, since otherwise the assembler rejects some code which makes use of an extended instruction set (AltiVec extensions I think). (See http://trac.sagemath.org/sage_trac/ticket/8664#comment:47 ff. Interestingly, this apparently wasn't necessary on a MacOS X 10.4 PowerPC G5, with XCode GCC 4.0.1.) (We also remove a lot of x86 assembly code on 32-bit MacOS X 10.4 and 10.5 Intel due to PIC issues, though I'm not sure if this is really still necessary.) -Leif -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
