http://blog.gmane.org/gmane.comp.lib.mpfr.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.lib.mpfr.general/1651 <pre>There is a growing interest for implementation of mpfr_t to __float128 converters. This topic was discussed before: http://comments.gmane.org/gmane.comp.lib.mpfr.general/764 And it is one of the questions for MPFR Workshop 2012. I am not sure if this was already discussed but there are mpfr_t to __float128 converters created by libquadmath (__float128) developers available here: http://gcc.gnu.org/ml/fortran/2011-02/msg00218.html I have no idea about the quality of the code, maybe it can be used until final implementation in MPFR (or at least considered as a starting point). It would be very helpful, if someone knowledgeable could provide feedback for the code - is there are any obvious/hidden problems, suggestions for improvement, etc. Pavel Holoborodko. </pre> Pavel Holoborodko 2012-05-18T11:20:11 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1647 <pre>Hi I'm using the MPFR on a Mac PPC platform (OSX 10.4) and everything works well. Now I'm trying to port the application to a Mac Intel platform (OSX 10.7.3) and the "mpfr_const_" functions fail. A simple test program for mpfr_const_euler() and mpfr_const_pi() on the PPC machine gives correct results like: Last login: Wed May 16 23:32:01 on ttyp1 Welcome to Darwin! 84-75-166-14:~ vk$ cc -o tconst ~/Desktop/tconst.c -lmpfr -lgmp 84-75-166-14:~ vk$ ~/tconst GMP version 5.0.4 MPFR version 3.1.0-p10 gamma at 32 = 5.7721566479e-01 cached gamma at 32 = 5.7721566479e-01 pi at 32 = 3.1415926535e+00 cached pi at 32 = 3.1415926535e+00 gamma at 66 = 5.77215664901532860603e-01 cached gamma at 66 = 5.77215664901532860603e-01 pi at 66 = 3.14159265358979323846e+00 cached pi at 66 = 3.14159265358979323846e+00 gamma at 100 = 5.7721566490153286060651209008234e-01 cached gamma at 100 = 5.7721566490153286060651209008234e-01 pi at 100 = 3.1415926535897932384626433832793e+00 cached pi at 100 = 3.1415926535897932384626433832793e+00 gamma at 200 = 5.7721566490153286060651209008240243104215933593992359880576723e-01 cached gamma at 200 = 5.7721566490153286060651209008240243104215933593992359880576723e-01 pi at 200 = 3.1415926535897932384626433832795028841971693993751058209749445e+00 cached pi at 200 = 3.1415926535897932384626433832795028841971693993751058209749445e+00 The same program on the Mac Intel machine fails like: Last login: Thu May 17 00:07:17 on ttys002 vks-MacBook-Pro:~ vk$ gcc -arch i386 -o tconst ~/Desktop/tconst.c -lmpfr -lgmp -Wl,-no_pie vks-MacBook-Pro:~ vk$ ~/tconst GMP version 5.0.4 MPFR version 3.1.0-p3 cache.c:79: MPFR assertion failed: (((cache-&gt;x)-&gt;_mpfr_sign) &gt; 0) Abort trap: 6 vks-MacBook-Pro:~ vk$ gcc -o tconst ~/Desktop/tconst.c -lmpfr -lgmp -Wl,- no_pie vks-MacBook-Pro:~ vk$ ~/tconst GMP version 5.0.4 MPFR version 3.1.0-p3 gamma at 32 = 5.7721566479e-01 cached gamma at 32 = 5.7721566479e-01 pi at 32 = 3.1415926535e+00 cached pi at 32 = 3.1415926535e+00 gamma at 66 = 2.10331117010802357345e+00 cached gamma at 66 = 2.10331117010802357345e+00 pi at 66 = 3.22816365295097810475e+00 cached pi at 66 = 3.22816365295097810475e+00 cache.c:79: MPFR assertion failed: (((cache-&gt;x)-&gt;_mpfr_sign) &gt; 0) Abort trap: 6 vks-MacBook-Pro:~ vk$ What's the problem here and how can I fix it? Thanks, vk </pre> vk-ip8hFmXdfkpIrkc2zG8k/Q< at >public.gmane.org 2012-05-16T22:53:10 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1642 <pre> Attached patch fixes build of mpfr with automake 1.12 </pre> Nitin A Kamble 2012-05-08T17:12:14 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1641 <pre>Patch 10 for GNU MPFR 3.1.0 is available on the MPFR web site: http://www.mpfr.org/mpfr-3.1.0/#bugs It fixes the mpfr_gamma function around the overflow/underflow thresholds in the extended exponent range. Without this patch, MPFR can freeze on some particular inputs of mpfr_gamma. </pre> Vincent Lefevre 2012-05-07T21:31:10 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1637 <pre>I all mpfr_get_flt to process for overflow, denormal, &amp;c; the number is already rounded and I don't wish any further rounding. So I decided to specify round to zero rather than the rounding mode already employed in conversion, but this changed the value stored on overflow to be 0x7f7fffff rather than 7f800000, which I get with round to nearest. Is this intentional? The number in question is 0.53976e40, which has an exponent of 132, quite way off the scale. </pre> John P. Hartmann 2012-05-03T14:27:07 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1633 <pre>This example seems to round towards infinity regardless of sign. That is, the result is correct, when compared to IBM's HLASM, for a positive decimal value, but not for a negative one. The numbers are hexadecimal floating point. Precision in this case is 21 bits. - 000001F0 C612D684 155 dc eh'-1234564.51r6' + 000001F0 C612D685 155 dc eh'-1234564.51r6' I checked the round raw generic function and it does not to test for MPFR_RNDU (or MPFR_RNDD), but something it call might well do. (But my test cases for rounding mode 7 [MPFR_RNDD] pass.) I use mpfr_strtofr() to convert and round. I can supply trace data if desired. More failing tests: 236c236 &lt; 000001C8 C612D684 145 dc eh'-1234564.01r6' --- 241c241 &lt; 000001DC C612D684 150 dc eh'-1234564.50r6' --- 246c246 &lt; 000001F0 C612D684 155 dc eh'-1234564.51r6' --- 256c256 &lt; 00000218 C612D685 165 dc eh'-1234565.01r6' --- 261c261 &lt; 0000022C C612D685 170 dc eh'-1234565.50r6' --- 266c266 &lt; 00000240 C612D685 175 dc eh'-1234565.51r6' --- 271c271 &lt; 00000254 C612D686 180 dc eh'-1234566.50r6' --- </pre> John P. Hartmann 2012-05-02T14:05:22 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1627 <pre>Hello, I'm cross building mpfr-3.1.0-p9 (all patches applied) in 32 bits on an amd64 machine. Configure line: CC="gcc -m32" CXX="g++ -m32" ./configure --prefix=/usr \ --enable-shared --libdir=/usr/lib32 ABI=32 gcc version 4.6.3 (Debian 4.6.3-4). I have GMP installed from the debian packages (version 2:5.0.4+dfsg-1). "make" builds fine, "make check" tests fine until tgamma which is stuck forever. There is no such problem when trying the unpatched version, or just building the 64 bits version with "./configure &amp;&amp; make &amp;&amp; make check". config.log attached. Laurent. </pre> Laurent Fousse 2012-04-28T21:04:37 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1623 <pre>I just installed mpfr-devel-2.4.1-6.el6.x86_64 on a CentOS system. mpfr_get_flt used to return a float, just as mpfr_get_d returns a double. Truncating a double to float is not always exact, right? Any suggestions for a workaround? (Or is this just a case of a missing declaration in the h file?) </pre> John P. Hartmann 2012-04-27T13:52:29 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1619 <pre>Hi, I'm trying to emulate binary64 while calculating mpfr_gamma. I did something like below mpfr_init2(xa,53); mpfr_init2(xb,53); // set value of xb using mpfr_set_d(xb, -168.5, MPFR_RNDN); mpfr_set_emin (-1073); mpfr_set_emax (1024); i = mpfr_gamma (xa, xb, MPFR_RNDN); i = mpfr_subnormalize (xa, i, MPFR_RNDN); /* new ternary value */ when xb = -168.5 I'm getting -0.0 as result where as the actual result should be close to -9.57373... × 10^-304 http://www.wolframalpha.com/input/?i=gamma(-168.5) Is there a problem with what I'm doing? or is there a problem with mpfr_gamma() I'm using mpfr3.1.0 Please help on this. Thank you. Regards, Giridhar </pre> Giridhar Tammana 2012-04-26T15:07:45 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1617 <pre>After some discussion with Paul, I've implemented operations on groups of flags in a MPFR flags branch. This is a bit like what the IEEE 754-2008 and ISO C99 standards specify. Before I reintegrate this feature in the trunk, are there any comments? I've attached the corresponding patch generated from the merge. </pre> Vincent Lefevre 2012-04-26T11:38:47 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1616 <pre> Hi, on Thursday May 3, from 9:30 AM to about 11:30 AM (CEST), the mpfr-/zGXu1G9BXs&lt; at &gt;public.gmane.org list will be temporarily unavailable. Messages posted to the list will be queued and transmitted afterwards. After the move, the archives will still be available, but probably at a different address. The same will hold for the mpfr-announce mailing list, but I don't think any announce will be posted during those two hours :-) There are currently 115 subscribers on mpfr-/zGXu1G9BXvhvxM+mQhndA&lt; at &gt;public.gmane.org We thank all subscribers for keeping the high quality of this list. Best regards, Paul Zimmermann (acting as list administrator) </pre> Zimmermann Paul 2012-04-25T13:32:12 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1614 <pre>There's a problem with huge macro expansions in assertions, which currently occurs in the trunk: when the checked expression is stringized in the ASSERT_FAIL macro, one can get a large string, whose size may be longer than the ISO C90 string length limitation (509 characters). For instance, in ai.c: wprec = MPFR_ADD_PREC (prec, MPFR_INT_CEIL_LOG2 (prec) + 5 + cond + assumed_exponent); where #define MPFR_ADD_PREC(P,X) \ (MPFR_ASSERTN ((X) &lt;= MPFR_PREC_MAX - (P)), (P) + (X)) and for GCC (even when using "-ansi -pedantic-errors"): # define MPFR_INT_CEIL_LOG2(x) \ (MPFR_UNLIKELY ((x) == 1) ? 0 : \ __extension__ ({ int _b; mp_limb_t _limb; \ MPFR_ASSERTN ((x) &gt; 1); \ _limb = (x) - 1; \ MPFR_ASSERTN (_limb == (x) - 1); \ count_leading_zeros (_b, _limb); \ (GMP_NUMB_BITS - _b); })) Until now, we allowed MPFR to be compiled with any C90 compiler (well, with some requirements on the implementation). I'm wondering what to do. First, in practice, I suppose that there won't be any problem: * At least currently, very long strings are probably generated only for GCC and compatible compilers, which are not affected by such a string limitation by default. * If not, even current C90-only (and non-C99 in general) compilers probably don't have such a low limitation. When testing with the GCC "-ansi -pedantic-errors" options, one could add the -Wno-overlength-strings option to avoid the error. Now, I think that it would be better to avoid huge macro expansions in assertions (at least), because in case of assertion failure, the output message isn't really readable and meaningful. So, I suggest to avoid such huge expressions in macros. I can see 2 possible ways: * Use a temporary variable, e.g. in the above case (ai.c). This could also make the code more readable, the compilation should be faster, and the generated code could also be faster and smaller (since the common subexpression becomes more obvious). * Use a function call in MPFR_ASSERT* macros. For instance, #define MPFR_IS_PURE_FP(x) (!MPFR_IS_SINGULAR(x) &amp;&amp; \ (MPFR_ASSERTD ((MPFR_MANT(x)[MPFR_LAST_LIMB(x)] \ &amp; MPFR_LIMB_HIGHBIT) != 0), 1)) could be changed to: #define MPFR_IS_PURE_FP(x) (!MPFR_IS_SINGULAR(x) &amp;&amp; \ (MPFR_ASSERTD (check_normalized (x)), 1)) with a new internal function check_normalized(), that would check whether the MPFR number is normalized. In case of assertion failure, the name check_normalized would appear in the message instead of an obfuscated expression. Also, we do not use static inline functions yet, but this could be done in the future (even unconditionally, as it seems that GMP now requires them to be supported). That would be cleaner than some macros. Any comment? </pre> Vincent Lefevre 2012-04-23T12:43:52 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1609 <pre>Hello. I wonder if there is a easy way to generate C code from an given arithmetic expression that uses MPFR-calls for each operation? For example, I have text like "(a*b-c*cos(d+e)/2)". Is there any automated way to transform such expressions into, at least a valid series, of MPFR-calls? Best Regards Robin Geyer </pre> robin.geyer-AK4bM3bY4sL4ajHJ1XSv27NAH6kLmebB< at >public.gmane.org 2012-04-23T10:08:40 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1608 <pre>Following the success of the 2011 meeting, we plan to hold another joint Mpfr/Mpc developer meeting. Date 25 June 2012, 14:00 to 27 June 2012, 12:00 Venue Institut de Mathématiques de Bordeaux, University of Bordeaux, France The goal of this meeting is to discuss future developments of the Gnu Mpfr and Gnu Mpc libraries. It is open to everyone interested in contributing to Gnu Mpfr and/or Gnu Mpc, be it by writing new code or by contributing new ideas. There is no registration fee, but please inform andreas.enge-MZpvjPyXg2s&lt; at &gt;public.gmane.org if you intend to participate, and indicate whether you agree that your name be mentioned on our website. If you are unable to come, but wish to contribute ideas or suggestions for topics we should treat, please feel free to voice them on our mailing list. Some travel support will be available upon request. More details to come at http://www.multiprecision.org/index.php?prog=mpc&amp;page=workshop2012 Andreas </pre> Andreas Enge 2012-04-19T15:11:18 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1606 <pre>Hi, I'm trying to use mpfr on ARM platform. I could get mpfr 3.0 but I need 3.1. How can I build mpfr (cross compile) for ARM platform? I tried building from svn://scm.gforge.inria.fr/svn/mpfr/branches/3.1 but there is no configure script. Please guide me how can I build for ARM platform? Regards, Giri </pre> giridhar.t-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org 2012-04-10T15:18:08 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1600 <pre>Hi there, I am new to MPFR and probably someone came up with the following issue. I am currently defining and using without problems this: int N = 1024, M=1024; mpfr_t matrix[N][M]; for(int r=0; r&lt;N; r++) for(int c=0; c&lt;M; c++) mpfr_init(matrix[r][c]); and was wondering which is the correct way of defining an equivalent using malloc. For instance, i tried with: mpfr_t** matrix = (mpfr_t**)malloc(sizeof(mpfr_t*) * N); for(int i=0; i&lt;N; i++) matrix[i] = (mpfr_t*)malloc(sizeof(mpfr_t) * M); for(int r=0; r&lt;N; r++) for(int c=0; c&lt;M; c++) mpfr_init(matrix[r][c]); which compiles errors free. However, the algorithm does not work as with first definition. Definitely, there is a mistake when using mallocs here. Since mpfr_t is a hidden type, i am stuck on this. Any help out there will be much appreciated. Thanks in advance. g </pre> German 2012-03-24T00:10:07 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1596 <pre>When building outside srcdir the tfpif test fails. Andreas. [tests/Makefile.am] Define SRCDIR as "$(srcdir)" [tests/tfpif.c] Use it to find input file --- tests/Makefile.am | 2 ++ tests/tfpif.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index 4ca3e2f..c7dab0c 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am &lt; at &gt;&lt; at &gt; -40,6 +40,8 &lt; at &gt;&lt; at &gt; check_PROGRAMS = tversion tinternals tinits tisqrt tsgn tcheck \ ttanh ttrunc tui_div tui_pow tui_sub turandom \ tvalist ty0 ty1 tyn tzeta tzeta_ui tversion +AM_CPPFLAGS = -DSRCDIR='"$(srcdir)"' + EXTRA_DIST = tgeneric.c tgeneric_ui.c mpf_compat.h inp_str.data tmul.dat \ mpfrtest.dat diff --git a/tests/tfpif.c b/tests/tfpif.c index 60118f8..1f41833 100644 --- a/tests/tfpif.c +++ b/tests/tfpif.c &lt; at &gt;&lt; at &gt; -23,7 +23,7 &lt; at &gt;&lt; at &gt; http://www.gnu.org/licenses/ or write to the Free Software Foundation, Inc., #include "mpfr-test.h" #define FILE_NAME_RW "mpfrtest.txt" /* temporary name (written then read) */ -#define FILE_NAME_R "mpfrtest.dat" /* fixed file name (read only) */ +#define FILE_NAME_R SRCDIR "/mpfrtest.dat" /* fixed file name (read only) */ int main (int argc, char *argv[]) </pre> Andreas Schwab 2012-03-20T12:33:45 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1595 <pre>This patch adds the function mpfr_fmod2 which is like mpfr_fmod, but also returns the low bits of the quotient. Background: I have written an emulation for the MC68882 FPU (as part of ARAnyM, see &lt;http://aranym.org&gt;) using mpfr as the backend. The MC68882 insn FMOD computes the modulo remainder in RZ mode and also returns the low 7 bits of the quotient. In order to emulate this insn I had to reimplement the internal function mpfr_rem1, since mpfr_fmod discards the quotient value. The mpfr_fmod2 function would make that unnecessary. Andreas. [src/rem1.c,src/mpfr.h] Add mpfr_fmod2 [doc/mpfr.texi] Document it --- doc/mpfr.texi | 7 ++++--- src/mpfr.h | 2 ++ src/rem1.c | 9 ++++++++- 3 files changed, 14 insertions(+), 4 deletions(-) diff --git a/doc/mpfr.texi b/doc/mpfr.texi index 619b53d..4ff6ed8 100644 --- a/doc/mpfr.texi +++ b/doc/mpfr.texi &lt; at &gt;&lt; at &gt; -2525,13 +2525,14 &lt; at &gt;&lt; at &gt; corresponding precision of &lt; at &gt;var{iop} and &lt; at &gt;var{fop} (equivalent to &lt; at &gt;end deftypefun &lt; at &gt;deftypefun int mpfr_fmod (mpfr_t &lt; at &gt;var{r}, mpfr_t &lt; at &gt;var{x}, mpfr_t &lt; at &gt;var{y}, mpfr_rnd_t &lt; at &gt;var{rnd}) +&lt; at &gt;deftypefunx int mpfr_fmod2 (mpfr_t &lt; at &gt;var{r}, long* &lt; at &gt;var{q}, mpfr_t &lt; at &gt;var{x}, mpfr_t &lt; at &gt;var{y}, mpfr_rnd_t &lt; at &gt;var{rnd}) &lt; at &gt;deftypefunx int mpfr_remainder (mpfr_t &lt; at &gt;var{r}, mpfr_t &lt; at &gt;var{x}, mpfr_t &lt; at &gt;var{y}, mpfr_rnd_t &lt; at &gt;var{rnd}) &lt; at &gt;deftypefunx int mpfr_remquo (mpfr_t &lt; at &gt;var{r}, long* &lt; at &gt;var{q}, mpfr_t &lt; at &gt;var{x}, mpfr_t &lt; at &gt;var{y}, mpfr_rnd_t &lt; at &gt;var{rnd}) Set &lt; at &gt;var{r} to the value of &lt; at &gt;math{&lt; at &gt;var{x} - &lt; at &gt;var{n}&lt; at &gt;var{y}}, rounded according to the direction &lt; at &gt;var{rnd}, where &lt; at &gt;var{n} is the integer quotient of &lt; at &gt;var{x} divided by &lt; at &gt;var{y}, defined as follows: &lt; at &gt;var{n} is rounded -toward zero for &lt; at &gt;code{mpfr_fmod}, and to the nearest integer (ties rounded -to even) for &lt; at &gt;code{mpfr_remainder} and &lt; at &gt;code{mpfr_remquo}. +toward zero for &lt; at &gt;code{mpfr_fmod} and &lt; at &gt;code{mpfr_fmod2}, and to the nearest +integer (ties rounded to even) for &lt; at &gt;code{mpfr_remainder} and &lt; at &gt;code{mpfr_remquo}. Special values are handled as described in Section F.9.7.1 of the ISO C99 standard: &lt; at &gt;&lt; at &gt; -2541,7 +2542,7 &lt; at &gt;&lt; at &gt; to the precision of &lt; at &gt;var{r}. If &lt; at &gt;var{r} is zero, it has the sign of &lt; at &gt;var{x}. The return value is the ternary value corresponding to &lt; at &gt;var{r}. -Additionally, &lt; at &gt;code{mpfr_remquo} stores +Additionally, &lt; at &gt;code{mpfr_fmod2} and &lt; at &gt;code{mpfr_remquo} store the low significant bits from the quotient &lt; at &gt;var{n} in &lt; at &gt;var{*q} (more precisely the number of bits in a &lt; at &gt;code{long} minus one), with the sign of &lt; at &gt;var{x} divided by &lt; at &gt;var{y} diff --git a/src/mpfr.h b/src/mpfr.h index d3d7fbe..551b1c3 100644 --- a/src/mpfr.h +++ b/src/mpfr.h &lt; at &gt;&lt; at &gt; -587,6 +587,8 &lt; at &gt;&lt; at &gt; __MPFR_DECLSPEC int mpfr_remainder _MPFR_PROTO ((mpfr_ptr, mpfr_srcptr, mpfr_srcptr, mpfr_rnd_t)); __MPFR_DECLSPEC int mpfr_fmod _MPFR_PROTO ((mpfr_ptr, mpfr_srcptr, mpfr_srcptr, mpfr_rnd_t)); +__MPFR_DECLSPEC int mpfr_fmod2 _MPFR_PROTO ((mpfr_ptr, long*, mpfr_srcptr, + mpfr_srcptr, mpfr_rnd_t)); __MPFR_DECLSPEC int mpfr_fits_ulong_p _MPFR_PROTO((mpfr_srcptr, mpfr_rnd_t)); __MPFR_DECLSPEC int mpfr_fits_slong_p _MPFR_PROTO((mpfr_srcptr, mpfr_rnd_t)); diff --git a/src/rem1.c b/src/rem1.c index a3f91f0..9d17dc8 100644 --- a/src/rem1.c +++ b/src/rem1.c &lt; at &gt;&lt; at &gt; -1,5 +1,5 &lt; at &gt;&lt; at &gt; /* mpfr_rem1 -- internal function - mpfr_fmod -- compute the floating-point remainder of x/y + mpfr_fmod and mpfr_fmod2 -- compute the floating-point remainder of x/y mpfr_remquo and mpfr_remainder -- argument reduction functions Copyright 2007, 2008, 2009, 2010, 2011, 2012 Free Software Foundation, Inc. &lt; at &gt;&lt; at &gt; -227,3 +227,10 &lt; at &gt;&lt; at &gt; mpfr_fmod (mpfr_ptr rem, mpfr_srcptr x, mpfr_srcptr y, mpfr_rnd_t rnd) { return mpfr_rem1 (rem, (long *) 0, MPFR_RNDZ, x, y, rnd); } + +int +mpfr_fmod2 (mpfr_ptr rem, long *quo, + mpfr_srcptr x, mpfr_srcptr y, mpfr_rnd_t rnd) +{ + return mpfr_rem1 (rem, quo, MPFR_RNDZ, x, y, rnd); +} </pre> Andreas Schwab 2012-03-20T11:51:06 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1592 <pre>Hi, I am trying to build MPFR 3.1.0 so that I can build a newer version of gcc. I am getting an error in the tests when doing a make check. Any help would be appreciated. $ ./configure checking for a BSD-compatible install... ./install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking whether to disable maintainer-specific portions of Makefiles... yes checking build system type... powerpc-ibm-aix7.1.0.0 checking host system type... powerpc-ibm-aix7.1.0.0 checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for a sed that does not truncate output... /usr/bin/sed checking for CC and CFLAGS in gmp.h... yes CC=/usr/vacpp/bin/xlc_r -O2 CFLAGS=-O2 checking for CC=/usr/vacpp/bin/xlc_r -O2 and CFLAGS=-O2... yes checking for gcc... /usr/vacpp/bin/xlc_r -O2 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... no checking whether /usr/vacpp/bin/xlc_r -O2 accepts -g... yes checking for /usr/vacpp/bin/xlc_r -O2 option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of /usr/vacpp/bin/xlc_r -O2... aix checking how to run the C preprocessor... /usr/vacpp/bin/xlc_r -O2 -E checking for ICC... no checking whether /usr/vacpp/bin/xlc_r -O2 and cc understand -c and -o together... yes checking for function prototypes... yes checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for string.h... (cached) yes checking for an ANSI C-conforming const... yes checking for working volatile... yes checking for main in -lm... yes checking whether time.h and sys/time.h may both be included... yes checking for size_t... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking float.h usability... yes checking float.h presence... yes checking for float.h... yes checking for string.h... (cached) yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking stdarg.h usability... yes checking stdarg.h presence... yes checking for stdarg.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/fpu.h usability... no checking sys/fpu.h presence... no checking for sys/fpu.h... no checking for working alloca.h... yes checking for alloca... yes checking for stdint.h... (cached) yes checking for SIZE_MAX... yes checking how to copy va_list... va_copy checking for memmove... yes checking for memset... yes checking for setlocale... yes checking for strtol... yes checking for gettimeofday... yes checking for long long int... yes checking for intmax_t... yes checking for working INTMAX_MAX... yes checking for union fpc_csr... no checking for fesetround... yes checking for denormalized numbers... yes checking if the FP division by 0 fails... no checking if NAN == NAN... no checking if charset has consecutive values... yes checking for math/round... yes checking for math/trunc... yes checking for math/floor... yes checking for math/ceil... yes checking for math/rint... yes checking for long double... yes checking format of `long double' floating point... IEEE double, big endian configure: WARNING: oops, unrecognised float format: IEEE double, big endian checking for TLS support... no checking for gmp.h... yes checking how to print strings... print -r checking for a sed that does not truncate output... (cached) /usr/bin/sed checking for fgrep... /usr/bin/grep -F checking for non-GNU ld... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 786432 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... no checking how to convert powerpc-ibm-aix7.1.0.0 file names to powerpc-ibm-aix7.1.0.0 format... func_convert_file_noop checking how to convert powerpc-ibm-aix7.1.0.0 file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... dlltool checking how to associate runtime and link libraries... print -r -- checking for ar... ar checking for archiver &lt; at &gt;FILE support... no checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from /usr/vacpp/bin/xlc_r -O2 object... ok checking for sysroot... no checking for mt... mt checking if mt is a manifest tool... no checking for dlfcn.h... yes checking for objdir... .libs checking for /usr/vacpp/bin/xlc_r -O2 option to produce PIC... -DPIC checking if /usr/vacpp/bin/xlc_r -O2 PIC flag -DPIC works... yes checking if /usr/vacpp/bin/xlc_r -O2 static flag -bnso -bI:/lib/syscalls.exp works... no checking if /usr/vacpp/bin/xlc_r -O2 supports -c -o file.o... yes checking if /usr/vacpp/bin/xlc_r -O2 supports -c -o file.o... (cached) yes checking whether the /usr/vacpp/bin/xlc_r -O2 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... aix7.1.0.0 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking whether gcc __attribute__ ((mode (XX))) works... yes checking for recent GMP... yes checking for __gmpz_init in -lgmp... yes checking if gmp.h version and libgmp version are the same... (5.0.1/5.0.1) yes checking if gmp_printf supports "%jd"... yes checking if gmp_printf supports "%hhd"... yes checking if gmp_printf supports "%lld"... yes checking if gmp_printf supports "%Lf"... yes checking if gmp_printf supports "%td"... yes checking for __gmpn_rootrem... yes checking for __gmpn_sbpi1_divappr_q... yes configure: creating ./config.status config.status: creating Makefile config.status: creating doc/Makefile config.status: creating src/Makefile config.status: creating tests/Makefile config.status: creating tune/Makefile config.status: creating src/mparam.h config.status: executing depfiles commands config.status: executing libtool commands When I run make check I get the following results for the tests: make check-TESTS [tversion] GMP: header 5.0.1, library 5.0.1 [tversion] MPFR tuning parameters from src/powerpc32/mparam.h PASS: tversion PASS: tinternals PASS: tinits PASS: tisqrt PASS: tsgn PASS: tcheck PASS: tisnan PASS: texceptions PASS: tset_exp PASS: tset PASS: mpf_compat PASS: mpfr_compat PASS: reuse PASS: tabs PASS: tacos PASS: tacosh PASS: tadd PASS: tadd1sp PASS: tadd_d PASS: tadd_ui PASS: tagm PASS: tai PASS: tasin PASS: tasinh PASS: tatan PASS: tatanh PASS: taway PASS: tbuildopt PASS: tcan_round PASS: tcbrt PASS: tcmp PASS: tcmp2 PASS: tcmp_d PASS: tcmp_ld PASS: tcmp_ui PASS: tcmpabs PASS: tcomparisons PASS: tconst_catalan PASS: tconst_euler const_log2: error for large prec FAIL: tconst_log2 Timothy Grunewald Sr. Software Engineer Thomson Reuters Phone: 262-814-2892 Mobile: 262-501-4227 timothy.grunewald-qs4m+OjfQoH+fug3k4jHmNBPR1lH4CV8&lt; at &gt;public.gmane.org thomsonreuters.com </pre> timothy.grunewald-qs4m+OjfQoH+fug3k4jHmNBPR1lH4CV8< at >public.gmane.org 2012-03-07T16:47:30 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1579 <pre>Hi, I've been trying to build an Android NDK with a fresher toolchain, and I tried to use the latest mpfr release for that. The build was failing during mpc linkage because libmpfr.lai had broken dependency_libs, which, in turn, seems due to libtool (using a different libtool script did create a non broken libmpfr.lai). Cheers, Mike </pre> Mike Hommey 2012-03-05T12:19:39 http://comments.gmane.org/gmane.comp.lib.mpfr.general/1575 <pre>Hi, I experience a problem with mpfr_exp(rop,op,MPFR_RNDU). Typically mpfr_exp() gets the desired result within milli-seconds which is great! But if the result is a (positive) integer power of 2 then mpfr_exp() can hang for a long time, before coming up with the correct answer. For instance, computing mpfr_exp(rop,op,MPFR_RNDU) at 10000 digits of precision with op set to the value of log(17) is done instantaneously, but with op set to the value of log(16) it takes more than a minute on my 2.6 GHz machine. As a test case you may run the program 'mpfr_exp-timings.c' given below and see whether you can reproduce the results listed below. Best wishes, Holger $ cat mpfr_exp-timings.c #include&lt;stdio.h&gt; #include&lt;time.h&gt; #include&lt;gmp.h&gt; #include&lt;mpfr.h&gt; int main() { unsigned long i; double t; time_t t1,t2; mpfr_t op,rop; printf("GMP version %s\n",gmp_version); printf("MPFR version %s\n",mpfr_get_version()); printf("Some timings for mpfr_exp(rop,op,MPFR_RNDU):\n"); mpfr_init2(op,10000l); mpfr_init2(rop,10000l); for(i=19; i&gt;0; i--) { mpfr_set_ui(rop,i,MPFR_RNDU); mpfr_log(op,rop,MPFR_RNDU); printf("op=log(%lu), ",i); printf("mpfr_exp(rop,op,MPFR_RNDU) takes ..."); fflush(stdout); t1=clock(); mpfr_exp(rop,op,MPFR_RNDU); t2=clock(); t=difftime(t2,t1)/CLOCKS_PER_SEC; printf(" %g secs.\n",rop,t); fflush(stdout); } return 0; } $ gcc mpfr_exp-timings.c -lgmp -lmpfr $ a.out GMP version 4.3.2 MPFR version 3.0.0-p3 Some timings for mpfr_exp(rop,op,MPFR_RNDU): op=log(19), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. op=log(18), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. op=log(17), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. op=log(16), mpfr_exp(rop,op,MPFR_RNDU) takes ... 75.7 secs. op=log(15), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. op=log(14), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. op=log(13), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. op=log(12), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. op=log(11), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. op=log(10), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. op=log(9), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. op=log(8), mpfr_exp(rop,op,MPFR_RNDU) takes ... 75.62 secs. op=log(7), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. op=log(6), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. op=log(5), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. op=log(4), mpfr_exp(rop,op,MPFR_RNDU) takes ... 75.61 secs. op=log(3), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. op=log(2), mpfr_exp(rop,op,MPFR_RNDU) takes ... 75.57 secs. op=log(1), mpfr_exp(rop,op,MPFR_RNDU) takes ... 0 secs. $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.5 (Debian 4.4.5-8) $ uname -a Linux math-pc 2.6.32-5-amd64 #1 SMP Mon Jan 16 16:22:28 UTC 2012 x86_64 GNU/Linux </pre> Holger Then 2012-03-02T16:42:00 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.mpfr.general