tag:old.nabble.com,2006:forum-1658Nabble - Gnu - GMP2009-07-08T01:21:27ZGMP is a free library for arbitrary precision arithmetic, operating on signed integers, rational numbers, and floating point numbers. GMP is faster than any other bignum library. The advantage for GMP increases with the operand sizes for many operations, since GMP uses asymptotically faster algorithms. Gnu - GMP home is <a href="http://swox.com/gmp/" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-24387388t-popc.pm Test Fails With "Access to undefined memory"2009-07-08T01:21:27Z2009-07-08T01:21:27Zbornlibra23Hello People
<br>I am trying to port gmp library on Stratus VOS platform. Surprisingly the code compiled & built with little changes. However I am facing problems in the tests. The test t-popc.pm fails with "Access to undefined memory". It results in a sigbus signal to be delivered. The below is the trace of the program. Can anyone suggest something?
<br>GNU gdb 5.3
<br>Copyright 2002 Free Software Foundation, Inc.
<br>GDB is free software, covered by the GNU General Public License, and you are
<br>welcome to change it and/or distribute copies of it under certain conditions.
<br>Type "show copying" to see the conditions.
<br>There is absolutely no warranty for GDB. Type "show warranty" for details.
<br>This GDB was configured as "i686-stratus-vos"...
<br>(gdb) r
<br>Starting program: /posixPorted/gmp-4.3.1>tests>t-popc.pm
<br><br>Program received signal SIGBUS, Bus error.
<br>0x0004e561 in exit ()
<br> at exit.c:89
<br>89 exit.c: No such file or directory..
<br> in exit.c
<br>(gdb) bt
<br>#0 0x0004e561 in exit
<br> () at exit.c:89
<br>#1 0x00002dc9 in main
<br> () at t-popc.c:65
<br>#2 0x00002671 in s$start_c_program ()
<br> at s_start_c_program.c:283
<br>#3 0x80442393 in start_user_program ()<p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Dev-f1662.html" embed="fixTarget[1662]" target="_top" >Gnu - GMP - Dev</a></p>tag:old.nabble.com,2006:post-23996551Bounding the recursion depth of toom22_mul2009-06-12T03:41:09Z2009-06-12T03:41:09Znisse-4The storage need for toom22_mul includes a log term. One simple (but
<br>still quite conservative) bound is
<br><br> 2*(n + k)
<br><br>where n is the number of limbs in the larger factor (an), and k is the
<br>recursion depth. It's tempting to bound k by
<br><br> ceil(log_2(ceil(TOOM33_MUL_THRESHOLD / TOOM22_MUL_THRESHOLD)))
<br><br>which usually is a compile time constant. Then for safety one should
<br>probably also add an
<br><br> ASSERT_ALWAYS(BELOW_THRESHOLD(an, TOOM33_MUL_THRESHOLD));
<br><br>at the start of toom22_mul. I see some potential problems with this,
<br>though.
<br><br>1. The case of tuneup and fat binaries, where the thresholds are not
<br> constant. log_2 (TOOM33_MUL_THRESHOLD_LIMIT) might be of some use,
<br> but I'm not sure how that is intended to be used. Even better if
<br> there also was a *lower* bound on TOOM22_MUL_THRESHOLD, so one
<br> could in effect use MAX(TOOM33_MUL_THRESHOLD) /
<br> MIN(TOOM22_MUL_THRESHOLD).
<br><br>2. The recurson depth is related to the size of the larger input,
<br> while I think it is common to apply the thresholds looking at the
<br> smaller input. The above bound would break down if toom22_mul is
<br> callled with an above the toom33 threshold and bn below it.
<br><br>3. It makes it harder to include toom22 in benchmarks for larger
<br> sizes.
<br>
<br>There may be other problems that I'm missing.
<br><br>What's the maximum recursion depth in the usual configurations?
<br><br>Other alternatives might be to not care, and let a multiplication
<br>just above the Karatsuba threshold allocate some 128+ unused limbs. Or
<br>we could handle the case of a recursion depth of 1 (recursive calls
<br>all schoolbook) specially, if that is a common and important cases.
<br><br>Regards,
<br>/Niels
<br>_______________________________________________
<br>gmp-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23996551&i=0" target="_top" rel="nofollow">gmp-devel@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-devel" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Dev-f1662.html" embed="fixTarget[1662]" target="_top" >Gnu - GMP - Dev</a></p>tag:old.nabble.com,2006:post-23969997Re: Toom symmetries2009-06-10T13:07:30Z2009-06-10T13:07:30Znisse-4<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23969997&i=0" target="_top" rel="nofollow">bodrato@...</a> writes:
<br><br>> As you can see, we have a lot of [x,0;0,x] blocks, this does not only mean
<br>> we have two matrices that are identical and can be interpolated with one
<br>> single function... we can do something better!
<br>> We can "recompose" couples of lines! We have:
<br><br>That's clever. To see if I understand this, let's consider the simplest
<br>four-point interpolation first. The number we're trying to construct
<br>is x=f(B), with
<br><br> f(t) = x_0 + x_1 t + x_2 t^2 + x_3 t^3
<br><br>and B is the power of two used for splitting. To start with, we are
<br>given
<br><br> w0 = f(0) = x0
<br> w1 = f(1) = x0 + x1 + x2 + x3
<br> w2 = f(-1) = x0 - x1 + x2 - x3
<br> w3 = f(oo) = x3
<br><br>First, a butterfly operation, replacing w1 and w2 by
<br><br> w1 = x1 + x3
<br> w2 = x0 + x2
<br><br>Then x2 = w2 - w0 and x1 = w1 - w3, so we can write
<br><br> x = w0 + (w1 - w3) B + (w2 - w0) B^2 + w3 B^3
<br> = -(w3 B - w0) + (w1 + w2 B) B + (w3 B - w0) B^2
<br><br>Let L w0 and H w0 be the low and high part of w0. Define
<br><br> y = w3 - H w0
<br> z = w1 + B w2
<br><br>Then we have
<br><br> x = Lw0 - y B + z B + y B^2
<br><br>or graphically
<br> B^4 B^3 B^2 B 1
<br> | | | | | |
<br> +---------+----+
<br> | - y |Lw0 |
<br> +-----+---------+
<br> | z |
<br> +---+---------------+
<br> | y |-Lw0|
<br> +---------+----+
<br><br>So the inputs to the recombination, at this stage, are y (2n limbs +
<br>sign), z (2n+1 limbs) and Lw0 (n limbs), for a total of 5n + 1 limbs.
<br>Compared to 8*n + 2 needed to represent the original w:s. We need
<br>scratch space for the recursive computations, and for the storage of
<br>z, but no more. (To compute z, put factors in the product area, first
<br>product in z, second in the product area, then do the butterflies and
<br>combination. w0 and w3 can be computed directly into the product area
<br>and combined into y.
<br><br>I don't fully understand the current toom32_mul, but maybe it's doing
<br>precisely this? The temporary allocation makes me suspicious, though:
<br><br>toom32_mul_itch returns 4*n + 2. toom32_mul does this,
<br><br> #define scratch_out scratch + 4 * n + 2
<br> [...]
<br> TOOM22_MUL_N_REC (vm1, asm1, bsm1, n, scratch_out);
<br>
<br>The recursive call is to toom22_mul, which needs ~ 2n limbs of scratch
<br>space, according to toom22_mul_itch, and this area is beyond the
<br>scratch area that toom32_mul asks for.
<br><br>Regards,
<br>/Niels
<br>_______________________________________________
<br>gmp-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23969997&i=1" target="_top" rel="nofollow">gmp-devel@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-devel" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Dev-f1662.html" embed="fixTarget[1662]" target="_top" >Gnu - GMP - Dev</a></p>tag:old.nabble.com,2006:post-23961960Re: Toom symmetries2009-06-10T06:08:15Z2009-06-10T06:08:15ZbodratoCiao,
<br><br>> Unfortunately, I have to underline it again... this strategy only works
<br>> for the Toom-and-a-half algorithms, I mean unbalanced only :-(
<br>>
<br>> Well, nothing stops us from over-sampling a balanced case in order to
<br>> invoke this new interpolation strategy...
<br><br>Maybe... As soon as the Fool-Toom-Tool implement it, we will know if this
<br>is a good idea :-D
<br><br>Marco
<br><br>--
<br><a href="http://bodrato.it/" target="_top" rel="nofollow">http://bodrato.it/</a><br><br>_______________________________________________
<br>gmp-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23961960&i=0" target="_top" rel="nofollow">gmp-devel@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-devel" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Dev-f1662.html" embed="fixTarget[1662]" target="_top" >Gnu - GMP - Dev</a></p>tag:old.nabble.com,2006:post-23962002Re: Toom symmetries2009-06-10T05:46:08Z2009-06-10T05:46:08ZAlberto ZanoniAlle 14:08, mercoledì 10 giugno 2009, David Harvey ha scritto:
<div class='shrinkable-quote'><br>> On Jun 10, 2009, at 3:00 AM, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23962002&i=0" target="_top" rel="nofollow">bodrato@...</a> wrote:
<br>> > There are a lot of tricks like this, the first one in Karatsuba
<br>> > (due to?)
<br>> > saving half an addition. There is one in Toom-3, saving half a sum
<br>> > again,
<br>> > and it is implemented in the current[1] interpolate_5pts, another in
<br>> > Toom-3.5, saving two half additions, implemented in interpolate_6pts.
<br>>
<br>> Marco,
<br>>
<br>> At some point I skimmed over your paper with Zanoni on the optimality
<br>> of Toom-Cook matrices; I recall your automated search did not take
<br>> into account these kind of tricks that merge the interpolation and
<br>> recomposition stages. Is this correct?
</div><br>Hi, I'm Alberto (Zanoni).
<br><br>Yes, it is. The paper deals only with the interpolation stage. We didn't
<br>consider its merging with evaluation and/or recomposition there.
<br><br>> Have you tried this since
<br>> writing the paper? It seems that it shouldn't be difficult in theory
<br>> to extend the search method, although I have no idea if it's
<br>> practical (the search spaces are very large...?).
<br><br>Just to know, in our case the search space - for interpolation only - for
<br>Toom-3.5 was analyzed in about one week of running time (while Toom-3 took
<br>just some seconds).
<br><br>It seems difficult to use the same tool from the very beginning of
<br>interpolation phase with higher Toom. In our paper, for higher Toom
<br>some "manual" steps had to be done, in order to have a sufficient number of
<br>zero entries in the matrix, so that the analysis could be done in reasonable
<br>time.
<br><br>This limitation was in practice the starting point to look for other
<br>techniques searching for optimization or generalization somewhere else
<br>(stages merging, use of the "divide by 2" technique, the "general" Toom using
<br>powers of 2,...)
<br><br>We didn't try to insert these techniques in our "old" automated search tool.
<br><br>Alberto
<br><br>_______________________________________________
<br>gmp-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23962002&i=1" target="_top" rel="nofollow">gmp-devel@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-devel" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Dev-f1662.html" embed="fixTarget[1662]" target="_top" >Gnu - GMP - Dev</a></p>tag:old.nabble.com,2006:post-23960913Re: Toom symmetries2009-06-10T05:08:54Z2009-06-10T05:08:54ZDavid Harvey-6<br>On Jun 10, 2009, at 3:00 AM, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23960913&i=0" target="_top" rel="nofollow">bodrato@...</a> wrote:
<br><br>> There are a lot of tricks like this, the first one in Karatsuba
<br>> (due to?)
<br>> saving half an addition. There is one in Toom-3, saving half a sum
<br>> again,
<br>> and it is implemented in the current[1] interpolate_5pts, another in
<br>> Toom-3.5, saving two half additions, implemented in interpolate_6pts.
<br><br>Marco,
<br><br>At some point I skimmed over your paper with Zanoni on the optimality
<br>of Toom-Cook matrices; I recall your automated search did not take
<br>into account these kind of tricks that merge the interpolation and
<br>recomposition stages. Is this correct? Have you tried this since
<br>writing the paper? It seems that it shouldn't be difficult in theory
<br>to extend the search method, although I have no idea if it's
<br>practical (the search spaces are very large...?).
<br><br>david
<br><br>_______________________________________________
<br>gmp-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23960913&i=1" target="_top" rel="nofollow">gmp-devel@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-devel" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Dev-f1662.html" embed="fixTarget[1662]" target="_top" >Gnu - GMP - Dev</a></p>tag:old.nabble.com,2006:post-23960804Re: Toom symmetries2009-06-10T05:02:56Z2009-06-10T05:02:56ZDavid Harvey-6<br>On Jun 10, 2009, at 3:00 AM, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23960804&i=0" target="_top" rel="nofollow">bodrato@...</a> wrote:
<br><br>> An addsub/2 can be useful here, currently the effect of
<br>> (a,b) <- ( (a+b)/2, (a-b)/2 )
<br>> is given by the sequence:
<br>> a <- (a+b)/2
<br>> b <- a-b
<br>> which implies one shift only.
<br><br>Ah yes of course, this is already better than what I suggested.
<br><br>david
<br><br>_______________________________________________
<br>gmp-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23960804&i=1" target="_top" rel="nofollow">gmp-devel@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-devel" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Dev-f1662.html" embed="fixTarget[1662]" target="_top" >Gnu - GMP - Dev</a></p>tag:old.nabble.com,2006:post-23959327Re: Toom symmetries2009-06-10T03:15:46Z2009-06-10T03:15:46ZTorbjorn Granlund-6<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23959327&i=0" target="_top" rel="nofollow">bodrato@...</a> writes:
<br><br> Unfortunately, I have to underline it again... this strategy only works
<br> for the Toom-and-a-half algorithms, I mean unbalanced only :-(
<br>
<br>Well, nothing stops us from over-sampling a balanced case in order to
<br>invoke this new interpolation strategy...
<br><br>--
<br>Torbjörn
<br>_______________________________________________
<br>gmp-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23959327&i=1" target="_top" rel="nofollow">gmp-devel@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-devel" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Dev-f1662.html" embed="fixTarget[1662]" target="_top" >Gnu - GMP - Dev</a></p>tag:old.nabble.com,2006:post-23957926Toom-Fool: a fool tool to generate Toom-Cook implementations for GMP2009-06-10T01:28:14Z2009-06-10T01:28:14ZbodratoCiao!
<br><br>Since Toom is back again on the mailing-list, I must officially announce
<br>the fool-toom-tool (name suggested by a comment Torbjorn wrote, but
<br>remember to pronounce it something like ful-To-om-tul, with a loong "o" in
<br>Toom, not an "u").
<br><br>I wrote an awful, ugly script, with GP-Pari, to automatically write
<br>functions like mpn_toom_interpolate_15pts() or mpn_toom115_mul()... Now it
<br>is far from perfect, but it somehow works, and if you want you can try it.
<br><br>The script can be found on my web-site
<br><a href="http://bodrato.it/toom-cook/Toom-Tool.html" target="_top" rel="nofollow">http://bodrato.it/toom-cook/Toom-Tool.html</a><br><br>How does it work?
<br>You need the "gp" interpreter installed, then try:
<br><br>echo "generateToomCode(6)"|gp -quiet ToomGenMPN.gp|head --lines=-1>tc6.c
<br><br>You will find in tc6.c a working Toom-6 implementation with the functions
<br>mpn_toom_interpolate_11pts, mpn_toom84_mul, mpn_toom75_mul, mpn_toom66_mul.
<br><br>You can test it with
<br>gcc -DWANT_ASSERT -DCHECK -O3 -lgmp tc6.c -o tc6test
<br>./tc6test 59 58
<br>It will test the code 'till it find an error...
<br><br>You can somehow tune the output: try
<br><br>echo "GMP_BITS_PER_LIMB=32;BE_VERBOSE=1;DO_ASSERT=1;generateToomCode(4.5)"
<br><br>This will write the Toom-4.5 (mpn_toom_interpolate_8pts) code, for a
<br>32-bits environment, with a lot more ASSERT() and comments.
<br><br>Limitations:
<br>- _interpolate_Npts should be correct from Toom-3.5 (6pts) and passes
<br>(some) tests up to Toom-8 (15pts)
<br>- evaluation for operands with less than four parts are not generated
<br>(e.g. no _toom63 nor _toom72, but only _toom54 for Toom-4.5)
<br>- border/corner-cases are not considered, this means that "n" must be
<br>large enough, and the most significant parts (the not necessarily full
<br>ones) too.
<br>- the set of points used is not the best one... but it allows an easy
<br>sequence generation
<br>- generated code depends on GMP_BITS_PER_LIMB...
<br>- no mixing between interpolation and recomposition parts... yet! A lot
<br>can be done for the Toom-and-a-half (as explained), but we can gain a lot
<br>also on the last part of the balanced Toom, starting from the divisions
<br>(included!).
<br><br>Bugs:
<br>- too many bugs to be reported :-)
<br><br>If you will play with this code, please report any observation to me or to
<br>the list.
<br><br>Let me know,
<br>Marco
<br><br>PS: next step, as soon as I have some free time, will be some speed test
<br>to have some more complete graphs than the ones I did before:
<br><a href="http://bodrato.it/software/toom.html#TCcomp" target="_top" rel="nofollow">http://bodrato.it/software/toom.html#TCcomp</a><br><br>--
<br><a href="http://bodrato.it/software/" target="_top" rel="nofollow">http://bodrato.it/software/</a><br><br>_______________________________________________
<br>gmp-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23957926&i=0" target="_top" rel="nofollow">gmp-devel@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-devel" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Dev-f1662.html" embed="fixTarget[1662]" target="_top" >Gnu - GMP - Dev</a></p>tag:old.nabble.com,2006:post-23956840Re: Toom symmetries2009-06-10T00:00:08Z2009-06-10T00:00:08ZbodratoCiao!
<br><br>>> The simplest example, 4 points,
<br><br>Unfortunately the best examples of symmetry came from the
<br>"Toom-and-a-half", Toom-2.5, Toom-3.5 and so on (as I called them with
<br>Zanoni). This means unbalanced only methods. The balanced always have an
<br>odd number of points...
<br><div class='shrinkable-quote'><br>>> 1 0 0 0
<br>>> 1 1 1 1
<br>>> 1 -1 1 -1
<br>>> 0 0 0 1
<br>>>
<br>>> After addsub/2, we have
<br>>>
<br>>> 1 0 0 0
<br>>> 0 1 0 1
<br>>> 1 0 1 0
<br>>> 0 0 0 1
</div><br>An addsub/2 can be useful here, currently the effect of
<br>(a,b) <- ( (a+b)/2, (a-b)/2 )
<br>is given by the sequence:
<br>a <- (a+b)/2
<br>b <- a-b
<br>which implies one shift only.
<br><br>In other sequences I wrote, you can find something like:
<br>a <- a+b
<br>b <- 2*b
<br>b <- a-b
<br>this should be replaced by addsub (avoiding the shift)
<br><br>> Hmmm... sorry to interrupt your train of thought, this gives me an
<br>> idea. Maybe you can delay some of the division by two until after
<br>> part of the recomposition?
<br>[...]
<br>> I haven't checked the operation count, but it seems plausible that
<br>> something like this could save half a shift.
<br><br>There are a lot of tricks like this, the first one in Karatsuba (due to?)
<br>saving half an addition. There is one in Toom-3, saving half a sum again,
<br>and it is implemented in the current[1] interpolate_5pts, another in
<br>Toom-3.5, saving two half additions, implemented in interpolate_6pts.
<br>But in this particular case, I can not see it, because with the currently
<br>implemented sequence we compute one shift only, not two...
<br><br>Anyway the general idea is good, mix the recomposition phase and the
<br>interpolation, to save some half-operations. I'll give a real example I
<br>developed some times ago (but I did not have the time to really
<br>implement/test it).
<br><br>Again, the trick works perfectly for any Toom-and-a-half, the example is
<br>Toom-4.5, i.e. interpolation_8pts. I start from the matrix Niels wrote:
<br><div class='shrinkable-quote'><br>>> For the next example, say we use eight points, 0, oo, 1, -1, 2, -2,
<br>>> 1/2, -1/2. The full matrix is
<br>>>
<br>>> 1 0 0 0 0 0 0 0
<br>>> 1 1 1 1 1 1 1 1
<br>>> 1 -1 1 -1 1 -1 1 -1
<br>>> 1 2 4 8 16 32 64 128
<br>>> 1 -2 4 -8 16 -32 64 -128
<br>>> 128 64 32 16 8 4 2 1
<br>>> 128 -64 32 -16 8 -4 2 -1
<br>>> 0 0 0 0 0 0 0 1
</div><br>Niels proposed the butterfly operations, I suggest something slightly
<br>different, removing also the values on the first and last columns, and
<br>with slightly different shifts, the result I need is:
<br><br> 1 0 0 0 0 0 0 0
<br> 0 1 0 1 0 1 0 0
<br> 0 0 1 0 1 0 1 0
<br> 0 1 0 4 0 16 0 0
<br> 0 0 1 0 4 0 16 0
<br> 0 16 0 4 0 1 0 0
<br> 0 0 16 0 4 0 1 0
<br> 0 0 0 0 0 0 0 1
<br><br>As you can see, we have a lot of [x,0;0,x] blocks, this does not only mean
<br>we have two matrices that are identical and can be interpolated with one
<br>single function... we can do something better!
<br>We can "recompose" couples of lines! We have:
<br><br>|==== r0 =====|
<br> ||==== r1 =====|
<br> ||==== r2 =====|
<br> ||==== r3 =====|
<br> ||==== r4 =====|
<br> ||==== r5 =====|
<br> ||==== r6 =====|
<br> |==== r7 =====|
<br>and we recompose some pairs to get
<br>|==== r0 =====|
<br> ||==== r1 and r2 =====|
<br> ||==== r3 and r4 =====|
<br> ||==== r5 and r6 =====|
<br> |==== r7 =====|
<br><br>then we can interpolate the internal matrix
<br><br> 1 1 1
<br> 1 4 16
<br>16 4 1
<br><br>only once, operating on slices that are 3/2 times longer than the original
<br>ones, thus saving one half on _every_ operation after this step:
<br>additions, shifts, divisions... everything.
<br><br>Moreover, interlacing also the evaluation steps, we can also save on
<br>memory footprint: here is the strategy.
<br><br>- split in slices of "n" limbs
<br>- evaluate in {0, oo} (2n limbs each)
<br>- for each "a"
<br> - evaluate in {a, -a} (2n limbs + carry, each)
<br> - butterfly and remove first/last column
<br> - partially recompose (only 3n limbs + carry, n limbs [and a carry] freed)
<br>- interpolate the inner matrix
<br><br>For example, Toom-4.5 should need for the interpolation phase: 2 values of
<br>2n limbs and 3 values of 3n limbs, a total of 13n limbs; instead of
<br>8*2n=16n limbs...
<br><br>It should not be hard to write a single generic function doing
<br>butterfly/remove/recompose for any {a} (if a is a power of 2).
<br><br>Unfortunately, I have to underline it again... this strategy only works
<br>for the Toom-and-a-half algorithms, I mean unbalanced only :-(
<br><br>Have a nice day :-D
<br>Marco
<br><br>[1]
<br><a href="http://gmplib.org:8000/gmp/file/79e81acfb9b3/mpn/generic/toom_interpolate_5pts.c#l134" target="_top" rel="nofollow">http://gmplib.org:8000/gmp/file/79e81acfb9b3/mpn/generic/toom_interpolate_5pts.c#l134</a><br><br>--
<br><a href="http://bodrato.it/toom-cook/" target="_top" rel="nofollow">http://bodrato.it/toom-cook/</a><br><br>_______________________________________________
<br>gmp-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23956840&i=0" target="_top" rel="nofollow">gmp-devel@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-devel" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Dev-f1662.html" embed="fixTarget[1662]" target="_top" >Gnu - GMP - Dev</a></p>tag:old.nabble.com,2006:post-23951509Re: Toom symmetries2009-06-09T14:19:17Z2009-06-09T14:19:17ZDavid Harvey-6<br>On Jun 9, 2009, at 4:11 PM, Niels Möller wrote:
<br><div class='shrinkable-quote'><br>> The simplest example, 4 points,
<br>>
<br>> w0 = f(0)
<br>> w1 = f(1)
<br>> w2 = f(-1)
<br>> w3 = f(oo)
<br>>
<br>> corresponds to the matrix
<br>>
<br>> 1 0 0 0
<br>> 1 1 1 1
<br>> 1 -1 1 -1
<br>> 0 0 0 1
<br>>
<br>> After addsub/2, we have
<br>>
<br>> 1 0 0 0
<br>> 0 1 0 1
<br>> 1 0 1 0
<br>> 0 0 0 1
</div><br>Hmmm... sorry to interrupt your train of thought, this gives me an
<br>idea. Maybe you can delay some of the division by two until after
<br>part of the recomposition?
<br><br>i.e.: instead of addsub/2, just do addsub, then you have
<br><br> 1 0 0 0
<br> 0 2 0 2
<br> 2 0 2 0
<br> 0 0 0 1
<br><br>i.e. if the output poly coefficients are c0, c1, c2, c3, you have
<br><br>c0
<br>2c1 + 2c3
<br>2c0 + 2c2
<br>c3
<br><br>Now start doing recomposition:
<br><br> |=== 2c1 + 2c3 ===|
<br> |=== 2c0 + 2c2 ===|
<br><br>Then divide by 2:
<br><br> |==== c1 + c3 ====|
<br> |==== c0 + c2 ====|
<br><br>Then continue as usual, i.e. subtract c3, c0 from right places, add
<br>them at beginning and end (and also use the hi(c0) - lo(c3)
<br>redundancy trick...), to get
<br><br>|====== c0 =======|
<br> |====== c1 =======|
<br> |====== c2 =======|
<br> |====== c3 =======|
<br><br>I haven't checked the operation count, but it seems plausible that
<br>something like this could save half a shift.
<br><br>> In total 12 subtractions, 2 left shifts, 5 right shifts and 2
<br>> divisions. This actually not so bad compared to the current code,
<br>> there's just one more left shift (and then evaluation obviously also
<br>> needs more shifts). Using the four points corresponding to a = sqrt(B)
<br>> = 2^{GMP_NUMB_BITS /2} might also be worth investigating, in this case
<br>> the same reduction procedure will involved only division by (B-1).
<br><br>I did try the 2^(GMP_NUMB_BITS/2) idea at some stage --- one
<br>difficulty is that the pointwise multiplications get slightly bigger.
<br><br>david
<br><br>_______________________________________________
<br>gmp-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23951509&i=0" target="_top" rel="nofollow">gmp-devel@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-devel" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Dev-f1662.html" embed="fixTarget[1662]" target="_top" >Gnu - GMP - Dev</a></p>tag:old.nabble.com,2006:post-23950448Toom symmetries2009-06-09T13:11:51Z2009-06-09T13:11:51Znisse-4Hi,
<br><br>I've been looking into switching points for interpolate_7pts, from (0,
<br>oo, 1, -1, 2, 1/2, -1/2) to (0, oo, +1, -1, 2, -2, 1/2). Evaluation
<br>and interpolation is equivalent for most practical purposes, so the
<br>reason I tried this was very mundane: Then I can reuse the same
<br>helper function for evaluation in 2 and -2 for both toom44 and toom43
<br>(the latter uses interpolation with the points 0, oo, 1, -1, 2, -2).
<br><br>This got me to look a little closer to the symmetries of the choosen
<br>points.
<br><br>The most symmetry we can have is if the set of points is invariant
<br>under both negation and inversion. Then the point set is a union of
<br>sets of the types
<br><br> {0, oo} Each point invariant under negation, and they are swapped
<br> by inversion.
<br>
<br> {1, -1} Each point invariant under inversion, and they are
<br> swapped by negation.
<br><br> {a, -a, 1/a, -1/a} Swapped pairwise by the two operations.
<br><br>For a point pair (a, -a), a reasonable interpolation strategy (which seems to
<br>be part of at least some of the optimal sequences) is to split in even
<br>and odd parts, by a butterfly-like operation
<br><br> (w_i, w_j) <- ( (w_i + w_j)/2, (w_i - w_j)/(2a) )
<br><br>Then one question is how to best do this, with current operations that
<br>would be either one addsub followed by two shifts, or one rshadd and
<br>and rshsub. A combined operation might be useful. Currently, I don't
<br>think any interpolation code uses addsub.
<br><br>Furthermore, if we also have symmetry under inversion for all points,
<br>then the resulting matrices for even and odd parts are the same!
<br><br>The simplest example, 4 points,
<br><br> w0 = f(0)
<br> w1 = f(1)
<br> w2 = f(-1)
<br> w3 = f(oo)
<br><br>corresponds to the matrix
<br><br> 1 0 0 0
<br> 1 1 1 1
<br> 1 -1 1 -1
<br> 0 0 0 1
<br><br>After addsub/2, we have
<br><br> 1 0 0 0
<br> 0 1 0 1
<br> 1 0 1 0
<br> 0 0 0 1
<br><br>We get (1, 0; 1,1) for the even coefficients and (1,1; 0,1) for the
<br>even coefficients, which only differ by permutation.
<br><br>For the next example, say we use eight points, 0, oo, 1, -1, 2, -2,
<br>1/2, -1/2. The full matrix is
<br><br> 1 0 0 0 0 0 0 0
<br> 1 1 1 1 1 1 1 1
<br> 1 -1 1 -1 1 -1 1 -1
<br> 1 2 4 8 16 32 64 128
<br> 1 -2 4 -8 16 -32 64 -128
<br> 128 64 32 16 8 4 2 1
<br> 128 -64 32 -16 8 -4 2 -1
<br> 0 0 0 0 0 0 0 1
<br><br>After butterfly operations on the ± pairs, we get
<br><br> 1 0 0 0 0 0 0 0
<br> 0 1 0 1 0 1 0 1
<br> 1 0 1 0 1 0 1 0
<br> 0 1 0 4 0 16 0 64
<br> 1 0 4 0 16 0 64 0
<br> 0 64 0 16 0 4 0 1
<br> 64 0 16 0 4 0 1 0
<br> 0 0 0 0 0 0 0 1
<br><br>We get an even part
<br><br> 1 0 0 0
<br> 1 1 1 1
<br> 1 4 16 64
<br> 64 16 4 1
<br><br>and an odd part
<br><br> 1 1 1 1
<br> 1 4 16 64
<br> 64 16 4 1
<br> 0 0 0 1
<br><br>which again are equivalent. We can use the same row operations for both
<br>matrices, which means that 8 point interpolation can be implemented
<br>compactly using butterfly operations and reductions of the above
<br>4x4 matrix as building blocks.
<br><br>Then the difficult question is choice of points. Next example with
<br>full symmetry like above would by 12 points, where we might dd the
<br>four points corresponding to a = 4, or a = 2^(GMP_NUMB_BITS) / 2.
<br><br>Also for 6 points, we will get more symmetry (and hence compactness of
<br>interpolation) if we use 1/2, -1/2 rather than +1 and -1. This is
<br>likely slower than the current strategy. Anyway, after butterflies, we
<br>get the same matrix
<br><br> 1 0 0
<br> 1 4 16
<br> 16 4 1
<br><br>for odd and even parts, which can be reduced by
<br><br> w1 = w1 - w0
<br> w2 = w2 - 16*w0
<br> w1 = (w1 - w2)/15
<br> w2 = (w2 - w1)/4
<br><br>(I think this sequence is close to optimal). The butterfly operations
<br>(with no special addsub primitive) would be
<br><br> w2 = (w1 - w2)/2
<br> w1 = w1 - w2
<br> w4 = (w3 - w4)/2
<br> w3 = (w3 - w4)/2
<br><br>In total 12 subtractions, 2 left shifts, 5 right shifts and 2
<br>divisions. This actually not so bad compared to the current code,
<br>there's just one more left shift (and then evaluation obviously also
<br>needs more shifts). Using the four points corresponding to a = sqrt(B)
<br>= 2^{GMP_NUMB_BITS /2} might also be worth investigating, in this case
<br>the same reduction procedure will involved only division by (B-1).
<br><br>/Niels
<br>_______________________________________________
<br>gmp-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23950448&i=0" target="_top" rel="nofollow">gmp-devel@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-devel" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Dev-f1662.html" embed="fixTarget[1662]" target="_top" >Gnu - GMP - Dev</a></p>tag:old.nabble.com,2006:post-23842117toom44_mul allocation2009-06-02T15:18:54Z2009-06-02T15:18:54Znisse-4Hi,
<br><br>I've reorganized tomm44_mul to avoid using TMP_ALLOC. The storage need
<br>for multiplying two n-limb numbers is now 8 n / 3 + log-term.
<br><br>The current mpn_toom44_mul_itch says 12 ceil(n/4) + GMP_NUMB_BITS. I
<br>think this should be sufficient and somewhat conservative, but I
<br>haven't analyzed the sub-linear term in detail. (For comparison, both
<br>toom22 and toom33 need 2 n + log term).
<br><br>The use of parts of the product area for temporaries may be somewhat
<br>irregular, but I think it's a pretty good strategy to evaluate at two
<br>points +x and -x at a time, and store these four (n+1)-limb numbers in
<br>the product area. Then the scratch space is needed to store 4 of the
<br>pointwise products (the other three are also stored in the product
<br>area in due time), and for the recursive multiplications.
<br><br>Regards,
<br>/Niels
<br><br><br />_______________________________________________
<br>gmp-devel mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23842117&i=0" target="_top" rel="nofollow">gmp-devel@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-devel" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-devel</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Dev-f1662.html" embed="fixTarget[1662]" target="_top" >Gnu - GMP - Dev</a></p>tag:old.nabble.com,2006:post-23831629Re: Documentation of __GMP_CC and __GMP_CFLAGS ?2009-06-02T05:28:33Z2009-06-02T05:28:33ZSisyphus<br>----- Original Message -----
<br>From: "Vincent Lefevre" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23831629&i=0" target="_top" rel="nofollow">vincent@...</a>>
<br><br>> IMHO, you shouldn't have a build failure if they are not present.
<br>> In such a case, the Perl value should just be undef.
<br><br>Yes - you're right. (Knew I was missing something ...)
<br><br>I'll modify it so that is precisely what happens.
<br><br>Cheers,
<br>Rob
<br>_______________________________________________
<br>gmp-discuss mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23831629&i=1" target="_top" rel="nofollow">gmp-discuss@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-discuss" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-discuss</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Discuss-f1661.html" embed="fixTarget[1661]" target="_top" >Gnu - GMP - Discuss</a></p>tag:old.nabble.com,2006:post-23831672Re: Documentation of __GMP_CC and __GMP_CFLAGS ?2009-06-02T05:24:18Z2009-06-02T05:24:18ZSisyphus<br>----- Original Message -----
<br>From: "Torbjorn Granlund" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23831672&i=0" target="_top" rel="nofollow">tg@...</a>>
<br><br>> > Are there any plans to document __GMP_CC and __GMP_CFLAGS in the future
<br>> > ?
<br>>
<br>> It seems like a good idea to document them.
<br><br>Excellent !!
<br><br>Thanks, Torbjorn.
<br><br>Cheers,
<br>Rob
<br><br>_______________________________________________
<br>gmp-discuss mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23831672&i=1" target="_top" rel="nofollow">gmp-discuss@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-discuss" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-discuss</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Discuss-f1661.html" embed="fixTarget[1661]" target="_top" >Gnu - GMP - Discuss</a></p>tag:old.nabble.com,2006:post-23831491Re: Documentation of __GMP_CC and __GMP_CFLAGS ?2009-06-02T05:18:35Z2009-06-02T05:18:35ZTorbjorn Granlund-6"Sisyphus" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23831491&i=0" target="_top" rel="nofollow">sisyphus1@...</a>> writes:
<br><br> Are there any plans to document __GMP_CC and __GMP_CFLAGS in the future ?
<br>
<br>It seems like a good idea to document them.
<br><br>(I think it was a mere oversight not to document them when they were
<br>introduced.)
<br><br>--
<br>Torbjörn
<br>_______________________________________________
<br>gmp-discuss mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23831491&i=1" target="_top" rel="nofollow">gmp-discuss@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-discuss" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-discuss</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Discuss-f1661.html" embed="fixTarget[1661]" target="_top" >Gnu - GMP - Discuss</a></p>tag:old.nabble.com,2006:post-23831470Re: Documentation of __GMP_CC and __GMP_CFLAGS ?2009-06-02T05:16:42Z2009-06-02T05:16:42ZVincent LefevreHi,
<br><br>On 2009-06-02 22:01:55 +1000, Sisyphus wrote:
<br>> Are there any plans to document __GMP_CC and __GMP_CFLAGS in the future ?
<br>>
<br>> I've made them accessible from (the perl module) Math::GMPz, because of
<br>> their potentially useful diagnostic capabilities ... but then I've also
<br>> received a complaint about that because they're not documented
<br>> ( <a href="https://rt.cpan.org/Ticket/Display.html?id=46604" target="_top" rel="nofollow">https://rt.cpan.org/Ticket/Display.html?id=46604</a> ).
<br>>
<br>> Knowing what (if anything) is planned in this regard might have a bearing
<br>> onhow I deal with that complaint.
<br><br>IMHO, you shouldn't have a build failure if they are not present.
<br>In such a case, the Perl value should just be undef.
<br><br>--
<br>Vincent Lefèvre <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23831470&i=0" target="_top" rel="nofollow">vincent@...</a>> - Web: <<a href="http://www.vinc17.org/" target="_top" rel="nofollow">http://www.vinc17.org/</a>>
<br>100% accessible validated (X)HTML - Blog: <<a href="http://www.vinc17.org/blog/" target="_top" rel="nofollow">http://www.vinc17.org/blog/</a>>
<br>Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
<br>_______________________________________________
<br>gmp-discuss mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23831470&i=1" target="_top" rel="nofollow">gmp-discuss@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-discuss" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-discuss</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Discuss-f1661.html" embed="fixTarget[1661]" target="_top" >Gnu - GMP - Discuss</a></p>tag:old.nabble.com,2006:post-23831335Documentation of __GMP_CC and __GMP_CFLAGS ?2009-06-02T05:01:55Z2009-06-02T05:01:55ZSisyphusHi,
<br><br>Are there any plans to document __GMP_CC and __GMP_CFLAGS in the future ?
<br><br>I've made them accessible from (the perl module) Math::GMPz, because of
<br>their potentially useful diagnostic capabilities ... but then I've also
<br>received a complaint about that because they're not documented
<br>( <a href="https://rt.cpan.org/Ticket/Display.html?id=46604" target="_top" rel="nofollow">https://rt.cpan.org/Ticket/Display.html?id=46604</a> ).
<br><br>Knowing what (if anything) is planned in this regard might have a bearing on
<br>how I deal with that complaint.
<br><br>Cheers,
<br>Rob
<br><br>_______________________________________________
<br>gmp-discuss mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23831335&i=0" target="_top" rel="nofollow">gmp-discuss@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-discuss" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-discuss</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Discuss-f1661.html" embed="fixTarget[1661]" target="_top" >Gnu - GMP - Discuss</a></p>tag:old.nabble.com,2006:post-23786527GMP problem2009-05-29T11:41:30Z2009-05-29T11:41:30Zabansal5Hello ,
<br><br>This is Ankur . I was trying to install gmp in unix today , which i think i installed it properly but i do not know how to
<br><br>COMPILE a program like :
<br><br><br> using namespace std;
<br><br> int main (void)
<br><br>{
<br> mpz_class a, b, c;
<br> a = 1234;
<br> b = "-5678";
<br> c = a+b;
<br> cout << "sum is " << c << "\n";
<br> cout << "absolute value is " << abs(c) << "\n";
<br> cin >> a;
<br> return 0;
<br> }
<br>
<br>you must include iostream and gmpxx.h files for the above program
<br>
<br>Say I am in dirctory like ~/gmp/gmp-4.2.1 , and three directories (include ,info , lib) are in ~/HPC
<br><br>Can you tell me the command how to compile this kind of program
<br><br>Thanks a lot
<br><br>Ankur
<br><br><br><br><br><br>_______________________________________________
<br>gmp-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23786527&i=0" target="_top" rel="nofollow">gmp-bugs@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-bugs" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Bugs-f1659.html" embed="fixTarget[1659]" target="_top" >Gnu - GMP - Bugs</a></p>tag:old.nabble.com,2006:post-23496625'make check' error2009-05-11T18:29:41Z2009-05-11T18:29:41ZTomohiko OuchiHello!
<br>I tried to compile gmp-4.3.0 on my Linux system.
<br>When I run 'make check', unfortunatly got error.
<br>I enclose check log.
<br><br>Our Linux system is below. (result of uname -a command)
<br>Linux mlsl103 2.4.21-54.ELsmp #1 SMP Wed Feb 20 15:43:56 EST 2008 x86_64
<br>x86_64 x86_64 GNU/Linux
<br><br>And gcc version is below (result of gcc -v command)
<br>Reading specs from /usr/lib/gcc-lib/x86_64-redhat-linux/3.2.3/specs
<br>Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
<br>--infodir=/usr/share/info
<br>--enable-shared --enable-threads=posix --disable-checking
<br>--with-system-zlib --enable-__cxa_atexit
<br>--host=x86_64-redhat-linux
<br>Thread model: posix
<br>gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-53)
<br><br>Thank you for your attention.
<br><br><br><br />make check-recursive
<br>make[1]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0'
<br>Making check in tests
<br>make[2]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests'
<br>Making check in .
<br>make[3]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests'
<br>make libtests.la t-bswap t-constants t-count_zeros t-gmpmax t-hightomask t-modlinv t-popc t-parity t-sub
<br>make[4]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests'
<br>make[4]: `libtests.la' is up to date.
<br>make[4]: `t-bswap' is up to date.
<br>make[4]: `t-constants' is up to date.
<br>make[4]: `t-count_zeros' is up to date.
<br>make[4]: `t-gmpmax' is up to date.
<br>make[4]: `t-hightomask' is up to date.
<br>make[4]: `t-modlinv' is up to date.
<br>make[4]: `t-popc' is up to date.
<br>make[4]: `t-parity' is up to date.
<br>make[4]: `t-sub' is up to date.
<br>make[4]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests'
<br>make check-TESTS
<br>make[4]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests'
<br>PASS: t-bswap
<br>PASS: t-constants
<br>PASS: t-count_zeros
<br>PASS: t-gmpmax
<br>PASS: t-hightomask
<br>PASS: t-modlinv
<br>PASS: t-popc
<br>PASS: t-parity
<br>PASS: t-sub
<br>==================
<br>All 9 tests passed
<br>==================
<br>make[4]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests'
<br>make[3]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests'
<br>Making check in devel
<br>make[3]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/devel'
<br>make[3]: Nothing to be done for `check'.
<br>make[3]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/devel'
<br>Making check in mpn
<br>make[3]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpn'
<br>make t-asmtype t-aors_1 t-divrem_1 t-fat t-get_d t-instrument t-iord_u t-mp_bases t-perfsqr t-scan t-hgcd t-matrix22
<br>make[4]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpn'
<br>make[4]: `t-asmtype' is up to date.
<br>make[4]: `t-aors_1' is up to date.
<br>make[4]: `t-divrem_1' is up to date.
<br>make[4]: `t-fat' is up to date.
<br>make[4]: `t-get_d' is up to date.
<br>make[4]: `t-instrument' is up to date.
<br>make[4]: `t-iord_u' is up to date.
<br>make[4]: `t-mp_bases' is up to date.
<br>make[4]: `t-perfsqr' is up to date.
<br>make[4]: `t-scan' is up to date.
<br>make[4]: `t-hgcd' is up to date.
<br>make[4]: `t-matrix22' is up to date.
<br>make[4]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpn'
<br>make check-TESTS
<br>make[4]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpn'
<br>PASS: t-asmtype
<br>PASS: t-aors_1
<br>PASS: t-divrem_1
<br>PASS: t-fat
<br>PASS: t-get_d
<br>PASS: t-instrument
<br>PASS: t-iord_u
<br>PASS: t-mp_bases
<br>PASS: t-perfsqr
<br>PASS: t-scan
<br>PASS: t-hgcd
<br>PASS: t-matrix22
<br>===================
<br>All 12 tests passed
<br>===================
<br>make[4]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpn'
<br>make[3]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpn'
<br>Making check in mpz
<br>make[3]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpz'
<br>make t-addsub t-cmp t-mul t-mul_i t-tdiv t-tdiv_ui t-fdiv t-fdiv_ui t-cdiv_ui t-gcd t-gcd_ui t-lcm dive dive_ui t-sqrtrem convert io t-inp_str logic bit t-powm t-powm_ui t-pow t-div_2exp reuse t-root t-perfsqr t-perfpow t-jac t-bin t-get_d t-get_d_2exp t-get_si t-set_d t-set_si t-fac_ui t-fib_ui t-lucnum_ui t-scan t-fits t-divis t-divis_2exp t-cong t-cong_2exp t-sizeinbase t-set_str t-aorsmul t-cmp_d t-cmp_si t-hamdist t-oddeven t-popcount t-set_f t-io_raw t-import t-export t-pprime_p t-nextprime
<br>make[4]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpz'
<br>make[4]: `t-addsub' is up to date.
<br>make[4]: `t-cmp' is up to date.
<br>make[4]: `t-mul' is up to date.
<br>make[4]: `t-mul_i' is up to date.
<br>make[4]: `t-tdiv' is up to date.
<br>make[4]: `t-tdiv_ui' is up to date.
<br>make[4]: `t-fdiv' is up to date.
<br>make[4]: `t-fdiv_ui' is up to date.
<br>make[4]: `t-cdiv_ui' is up to date.
<br>make[4]: `t-gcd' is up to date.
<br>make[4]: `t-gcd_ui' is up to date.
<br>make[4]: `t-lcm' is up to date.
<br>make[4]: `dive' is up to date.
<br>make[4]: `dive_ui' is up to date.
<br>make[4]: `t-sqrtrem' is up to date.
<br>make[4]: `convert' is up to date.
<br>make[4]: `io' is up to date.
<br>make[4]: `t-inp_str' is up to date.
<br>make[4]: `logic' is up to date.
<br>make[4]: `bit' is up to date.
<br>make[4]: `t-powm' is up to date.
<br>make[4]: `t-powm_ui' is up to date.
<br>make[4]: `t-pow' is up to date.
<br>make[4]: `t-div_2exp' is up to date.
<br>make[4]: `reuse' is up to date.
<br>make[4]: `t-root' is up to date.
<br>make[4]: `t-perfsqr' is up to date.
<br>make[4]: `t-perfpow' is up to date.
<br>make[4]: `t-jac' is up to date.
<br>make[4]: `t-bin' is up to date.
<br>make[4]: `t-get_d' is up to date.
<br>make[4]: `t-get_d_2exp' is up to date.
<br>make[4]: `t-get_si' is up to date.
<br>make[4]: `t-set_d' is up to date.
<br>make[4]: `t-set_si' is up to date.
<br>make[4]: `t-fac_ui' is up to date.
<br>make[4]: `t-fib_ui' is up to date.
<br>make[4]: `t-lucnum_ui' is up to date.
<br>make[4]: `t-scan' is up to date.
<br>make[4]: `t-fits' is up to date.
<br>make[4]: `t-divis' is up to date.
<br>make[4]: `t-divis_2exp' is up to date.
<br>make[4]: `t-cong' is up to date.
<br>make[4]: `t-cong_2exp' is up to date.
<br>make[4]: `t-sizeinbase' is up to date.
<br>make[4]: `t-set_str' is up to date.
<br>make[4]: `t-aorsmul' is up to date.
<br>make[4]: `t-cmp_d' is up to date.
<br>make[4]: `t-cmp_si' is up to date.
<br>make[4]: `t-hamdist' is up to date.
<br>make[4]: `t-oddeven' is up to date.
<br>make[4]: `t-popcount' is up to date.
<br>make[4]: `t-set_f' is up to date.
<br>make[4]: `t-io_raw' is up to date.
<br>make[4]: `t-import' is up to date.
<br>make[4]: `t-export' is up to date.
<br>make[4]: `t-pprime_p' is up to date.
<br>make[4]: `t-nextprime' is up to date.
<br>make[4]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpz'
<br>make check-TESTS
<br>make[4]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpz'
<br>PASS: t-addsub
<br>PASS: t-cmp
<br>PASS: t-mul
<br>PASS: t-mul_i
<br>PASS: t-tdiv
<br>PASS: t-tdiv_ui
<br>PASS: t-fdiv
<br>PASS: t-fdiv_ui
<br>PASS: t-cdiv_ui
<br>PASS: t-gcd
<br>PASS: t-gcd_ui
<br>PASS: t-lcm
<br>PASS: dive
<br>PASS: dive_ui
<br>PASS: t-sqrtrem
<br>PASS: convert
<br>PASS: io
<br>PASS: t-inp_str
<br>PASS: logic
<br>PASS: bit
<br>PASS: t-powm
<br>PASS: t-powm_ui
<br>PASS: t-pow
<br>PASS: t-div_2exp
<br>PASS: reuse
<br>PASS: t-root
<br>PASS: t-perfsqr
<br>PASS: t-perfpow
<br>PASS: t-jac
<br>PASS: t-bin
<br>PASS: t-get_d
<br>PASS: t-get_d_2exp
<br>PASS: t-get_si
<br>PASS: t-set_d
<br>PASS: t-set_si
<br>PASS: t-fac_ui
<br>PASS: t-fib_ui
<br>PASS: t-lucnum_ui
<br>PASS: t-scan
<br>PASS: t-fits
<br>PASS: t-divis
<br>PASS: t-divis_2exp
<br>PASS: t-cong
<br>PASS: t-cong_2exp
<br>PASS: t-sizeinbase
<br>PASS: t-set_str
<br>PASS: t-aorsmul
<br>PASS: t-cmp_d
<br>PASS: t-cmp_si
<br>PASS: t-hamdist
<br>PASS: t-oddeven
<br>PASS: t-popcount
<br>PASS: t-set_f
<br>PASS: t-io_raw
<br>PASS: t-import
<br>PASS: t-export
<br>PASS: t-pprime_p
<br>PASS: t-nextprime
<br>===================
<br>All 58 tests passed
<br>===================
<br>make[4]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpz'
<br>make[3]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpz'
<br>Making check in mpq
<br>make[3]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpq'
<br>make t-aors t-cmp t-cmp_ui t-cmp_si t-equal t-get_d t-get_str t-inp_str t-md_2exp t-set_f t-set_str
<br>make[4]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpq'
<br>make[4]: `t-aors' is up to date.
<br>make[4]: `t-cmp' is up to date.
<br>make[4]: `t-cmp_ui' is up to date.
<br>make[4]: `t-cmp_si' is up to date.
<br>make[4]: `t-equal' is up to date.
<br>make[4]: `t-get_d' is up to date.
<br>make[4]: `t-get_str' is up to date.
<br>make[4]: `t-inp_str' is up to date.
<br>make[4]: `t-md_2exp' is up to date.
<br>make[4]: `t-set_f' is up to date.
<br>make[4]: `t-set_str' is up to date.
<br>make[4]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpq'
<br>make check-TESTS
<br>make[4]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpq'
<br>PASS: t-aors
<br>PASS: t-cmp
<br>PASS: t-cmp_ui
<br>PASS: t-cmp_si
<br>PASS: t-equal
<br>PASS: t-get_d
<br>PASS: t-get_str
<br>PASS: t-inp_str
<br>PASS: t-md_2exp
<br>PASS: t-set_f
<br>PASS: t-set_str
<br>===================
<br>All 11 tests passed
<br>===================
<br>make[4]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpq'
<br>make[3]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpq'
<br>Making check in mpf
<br>make[3]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpf'
<br>make t-add t-sub t-conv t-sqrt t-sqrt_ui t-muldiv t-dm2exp reuse t-cmp_d t-cmp_si t-div t-fits t-get_d t-get_d_2exp t-get_si t-get_ui t-gsprec t-inp_str t-int_p t-mul_ui t-set t-set_q t-set_si t-set_ui t-trunc t-ui_div
<br>make[4]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpf'
<br>make[4]: `t-add' is up to date.
<br>make[4]: `t-sub' is up to date.
<br>make[4]: `t-conv' is up to date.
<br>make[4]: `t-sqrt' is up to date.
<br>make[4]: `t-sqrt_ui' is up to date.
<br>make[4]: `t-muldiv' is up to date.
<br>make[4]: `t-dm2exp' is up to date.
<br>make[4]: `reuse' is up to date.
<br>make[4]: `t-cmp_d' is up to date.
<br>make[4]: `t-cmp_si' is up to date.
<br>make[4]: `t-div' is up to date.
<br>make[4]: `t-fits' is up to date.
<br>make[4]: `t-get_d' is up to date.
<br>make[4]: `t-get_d_2exp' is up to date.
<br>make[4]: `t-get_si' is up to date.
<br>make[4]: `t-get_ui' is up to date.
<br>make[4]: `t-gsprec' is up to date.
<br>make[4]: `t-inp_str' is up to date.
<br>make[4]: `t-int_p' is up to date.
<br>make[4]: `t-mul_ui' is up to date.
<br>make[4]: `t-set' is up to date.
<br>make[4]: `t-set_q' is up to date.
<br>make[4]: `t-set_si' is up to date.
<br>make[4]: `t-set_ui' is up to date.
<br>make[4]: `t-trunc' is up to date.
<br>make[4]: `t-ui_div' is up to date.
<br>make[4]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpf'
<br>make check-TESTS
<br>make[4]: Entering directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpf'
<br>PASS: t-add
<br>PASS: t-sub
<br>PASS: t-conv
<br>PASS: t-sqrt
<br>PASS: t-sqrt_ui
<br>PASS: t-muldiv
<br>PASS: t-dm2exp
<br>PASS: reuse
<br>PASS: t-cmp_d
<br>mpf_cmp_si wrong on data[6]
<br> a=-0.1e1 (-1)
<br> b=1 (1)
<br> got=0
<br> want=-1
<br>FAIL: t-cmp_si
<br>PASS: t-div
<br>PASS: t-fits
<br>PASS: t-get_d
<br>PASS: t-get_d_2exp
<br>PASS: t-get_si
<br>PASS: t-get_ui
<br>PASS: t-gsprec
<br>PASS: t-inp_str
<br>PASS: t-int_p
<br>PASS: t-mul_ui
<br>PASS: t-set
<br>PASS: t-set_q
<br>PASS: t-set_si
<br>PASS: t-set_ui
<br>PASS: t-trunc
<br>PASS: t-ui_div
<br>==================================
<br>1 of 26 tests failed
<br>Please report to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23496625&i=0" target="_top" rel="nofollow">gmp-bugs@...</a>
<br>==================================
<br>make[4]: *** [check-TESTS] Error 1
<br>make[4]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpf'
<br>make[3]: *** [check-am] Error 2
<br>make[3]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests/mpf'
<br>make[2]: *** [check-recursive] Error 1
<br>make[2]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0/tests'
<br>make[1]: *** [check-recursive] Error 1
<br>make[1]: Leaving directory `/design02/ymkai/ouchito/OpenAccess/gmp-4.3.0'
<br>make: *** [check] Error 2
<br><br />_______________________________________________
<br>gmp-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23496625&i=1" target="_top" rel="nofollow">gmp-bugs@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-bugs" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Bugs-f1659.html" embed="fixTarget[1659]" target="_top" >Gnu - GMP - Bugs</a></p>tag:old.nabble.com,2006:post-23477467gmp install bug2009-05-10T22:15:14Z2009-05-10T22:15:14Z谭坚<DIV>Dear Miss/Mr.:</DIV>
<DIV> Hello,friend;</DIV>
<DIV> Here I have a hard time while I installed the gmp-4.2.2 in Linux4(64bit).And the gcc version is 3.4.</DIV>
<DIV> Now I try to describe wherethe bugs heppens; According to the requirement I input the command:"./configure " firstly and then"make",there is no error during the two steps. When the two procedures have successful completed，I input command line"make check" and run it ,then there are bugs here.</DIV>
<DIV>Here I list parts of the information:</DIV>
<DIV>.........</DIV>
<DIV><FONT color="#f00000">make check-TESTS</FONT></DIV>
<DIV><FONT color="#f00000">make[4]:Entering direstory'/root/Predicates/gmp-4.2.2/tests/mpf'</FONT></DIV>
<DIV><FONT color="#f00000">PASS: t-add</FONT></DIV>
<DIV><FONT color="#f00000">PASS: t-sub</FONT></DIV>
<DIV>.......</DIV>
<DIV><FONT color="#f00000">PASS: t-cmp_d</FONT></DIV>
<DIV><FONT color="#f00000">mpf_cmp_si wrong on data[6]</FONT></DIV>
<DIV><FONT color="#f00000"> a=-0.1e1(-1)</FONT></DIV>
<DIV><FONT color="#f00000"> b=1(1)<BR> got=0</FONT></DIV>
<DIV><FONT color="#f00000"> want=-1</FONT></DIV>
<DIV><FONT color="#f00000">FAIL: t-cmp_si</FONT></DIV>
<DIV><FONT color="#f00000">PASS: t-div</FONT></DIV>
<DIV>.........</DIV>
<DIV><FONT color="#f00000">PASS: t-ui_div</FONT></DIV>
<DIV><FONT color="#f00000">-----------------------------------------</FONT></DIV>
<DIV><FONT color="#f00000">1 of 26 tests failed</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>so ,I want you can have attention to this bug and I look forward to your reply. Thanks for your attention.<BR> May you have a nice day.</DIV>
<DIV> Sincerely: </DIV>
<DIV> Tanjian</DIV>
<DIV> 2009-05-11</DIV><br><!-- footer --><br><span title="neteasefooter" /><hr />
<a href="http://512.mail.163.com/mailstamp/stamp/dz/activity.do?from=footer" target="_top" rel="nofollow">穿越地震带 纪念汶川地震一周年</a>
</span><br />_______________________________________________
<br>gmp-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23477467&i=0" target="_top" rel="nofollow">gmp-bugs@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-bugs" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Bugs-f1659.html" embed="fixTarget[1659]" target="_top" >Gnu - GMP - Bugs</a></p>tag:old.nabble.com,2006:post-23347880[ANNOUNCE] GMP Language Bindings for Javascript/Flusspferd2009-05-02T07:07:16Z2009-05-02T07:07:16ZRüdiger Sonderfeld-2Hello,
<br>I started creating a GMP plugin for the Flusspferd library
<br>(<a href="http://flusspferd.org/" target="_top" rel="nofollow">http://flusspferd.org/</a>). Flusspferd provides Javascript bindings for C++, a
<br>Javascript interpreter and shell, and a Javascript/C++ module system.
<br><br>You can find the documentation here
<br> <a href="http://flusspferd.org/docs/js/gmp" target="_top" rel="nofollow">http://flusspferd.org/docs/js/gmp</a><br>and a small example here
<br> <a href="http://gist.github.com/105308" target="_top" rel="nofollow">http://gist.github.com/105308</a> .
<br><br>You can find the plugin in the git master tree.
<br><a href="http://github.com/ruediger/flusspferd/tree/master" target="_top" rel="nofollow">http://github.com/ruediger/flusspferd/tree/master</a><br><br>Regards,
<br>Rüdiger Sonderfeld
<br><br><br>_______________________________________________
<br>gmp-discuss mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23347880&i=0" target="_top" rel="nofollow">gmp-discuss@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-discuss" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-discuss</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Discuss-f1661.html" embed="fixTarget[1661]" target="_top" >Gnu - GMP - Discuss</a></p>tag:old.nabble.com,2006:post-23275488Re: GMP bugs2009-04-28T04:50:43Z2009-04-28T04:50:43ZTorbjorn Granlund-6Danny Goodman <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23275488&i=0" target="_top" rel="nofollow">goodman.danny@...</a>> writes:
<br><br> Hi,I just got the following error on 'make test' of the latest GMP version on my Mac OS 10.4.11. Please let me know if any other info would help debug this.best regards,dannymake check-TESTS
<br> PASS: t-addsubPASS: t-cmpPASS: t-mulPASS: t-mul_iPASS: t-tdivPASS: t-tdiv_uiPASS: t-fdivPASS: t-fdiv_uiPASS: t-cdiv_uiPASS: t-gcdPASS: t-gcd_uiPASS: t-lcmPASS: divePASS: dive_ui
<br> PASS: t-sqrtremPASS: convertPASS: ioPASS: t-inp_strPASS: logicPASS: bitPASS: t-powmPASS: t-powm_uiPASS: t-powPASS: t-div_2expPASS: reusePASS: t-rootPASS: t-perfsqrPASS: t-perfpow
<br> PASS: t-jacPASS: t-binPASS: t-get_dPASS: t-get_d_2expPASS: t-get_siPASS: t-set_dPASS: t-set_siPASS: t-fac_uiPASS: t-fib_uiPASS: t-lucnum_uiPASS: t-scanPASS: t-fitsPASS: t-divis
<br> PASS: t-divis_2expPASS: t-congPASS: t-cong_2expPASS: t-sizeinbasePASS: t-set_strPASS: t-aorsmulPASS: t-cmp_dPASS: t-cmp_simpz_hamdist wrong on 2 bits pos/pos i 0 j 32 got 253
<br> want 2 x =0x1 y =0x100000000FAIL: t-hamdistPASS: t-oddevenmpz_popcount wrong on single bit at 0 got 320, want 1FAIL: t-popcountPASS: t-set_fPASS: t-io_rawPASS: t-import
<br> PASS: t-exportPASS: t-pprime_pPASS: t-nextprime==================================2 of 58 tests failedPlease report to mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23275488&i=1" target="_top" rel="nofollow">gmp-bugs@...</a>==================================
<br> make[4]: *** [check-TESTS] Error 1make[3]: *** [check-am] Error 2make[2]: *** [check-recursive] Error 1make[1]: *** [check-recursive] Error 1make: *** [check] Error 2
<br><br>Thanks for the report!
<br><br>What exact machine type? A 32-bit or 64-bit build?
<br><br>Please see <a href="http://gmplib.org/manual/Reporting-Bugs.html" target="_top" rel="nofollow">http://gmplib.org/manual/Reporting-Bugs.html</a> for a full (but
<br>short!) list of the information we need for successfully handling a GMP
<br>bug report.
<br><br>--
<br>Torbjörn
<br>_______________________________________________
<br>gmp-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23275488&i=2" target="_top" rel="nofollow">gmp-bugs@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-bugs" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Bugs-f1659.html" embed="fixTarget[1659]" target="_top" >Gnu - GMP - Bugs</a></p>tag:old.nabble.com,2006:post-23275385GMP bugs2009-04-27T22:23:03Z2009-04-27T22:23:03ZDanny GoodmanHi,<br><br>I just got the following error on 'make test' of the latest GMP version on my Mac OS 10.4.11. Please let me know if any other info would help debug this.<br><br>best regards,<br>danny<br><br>make check-TESTS<br>
PASS: t-addsub<br>PASS: t-cmp<br>PASS: t-mul<br>PASS: t-mul_i<br>PASS: t-tdiv<br>PASS: t-tdiv_ui<br>PASS: t-fdiv<br>PASS: t-fdiv_ui<br>PASS: t-cdiv_ui<br>PASS: t-gcd<br>PASS: t-gcd_ui<br>PASS: t-lcm<br>PASS: dive<br>PASS: dive_ui<br>
PASS: t-sqrtrem<br>PASS: convert<br>PASS: io<br>PASS: t-inp_str<br>PASS: logic<br>PASS: bit<br>PASS: t-powm<br>PASS: t-powm_ui<br>PASS: t-pow<br>PASS: t-div_2exp<br>PASS: reuse<br>PASS: t-root<br>PASS: t-perfsqr<br>PASS: t-perfpow<br>
PASS: t-jac<br>PASS: t-bin<br>PASS: t-get_d<br>PASS: t-get_d_2exp<br>PASS: t-get_si<br>PASS: t-set_d<br>PASS: t-set_si<br>PASS: t-fac_ui<br>PASS: t-fib_ui<br>PASS: t-lucnum_ui<br>PASS: t-scan<br>PASS: t-fits<br>PASS: t-divis<br>
PASS: t-divis_2exp<br>PASS: t-cong<br>PASS: t-cong_2exp<br>PASS: t-sizeinbase<br>PASS: t-set_str<br>PASS: t-aorsmul<br>PASS: t-cmp_d<br>PASS: t-cmp_si<br>mpz_hamdist wrong on 2 bits pos/pos<br> i 0<br> j 32<br> got 253<br>
want 2<br> x =0x1<br> y =0x100000000<br>FAIL: t-hamdist<br>PASS: t-oddeven<br>mpz_popcount wrong on single bit at 0<br> got 320, want 1<br>FAIL: t-popcount<br>PASS: t-set_f<br>PASS: t-io_raw<br>PASS: t-import<br>
PASS: t-export<br>PASS: t-pprime_p<br>PASS: t-nextprime<br>==================================<br>2 of 58 tests failed<br>Please report to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23275385&i=0" target="_top" rel="nofollow">gmp-bugs@...</a><br>==================================<br>
make[4]: *** [check-TESTS] Error 1<br>make[3]: *** [check-am] Error 2<br>make[2]: *** [check-recursive] Error 1<br>make[1]: *** [check-recursive] Error 1<br>make: *** [check] Error 2<br>
<br />_______________________________________________
<br>gmp-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23275385&i=1" target="_top" rel="nofollow">gmp-bugs@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-bugs" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Bugs-f1659.html" embed="fixTarget[1659]" target="_top" >Gnu - GMP - Bugs</a></p>tag:old.nabble.com,2006:post-23150639Re: GMP 4.3.0 released2009-04-21T00:34:06Z2009-04-21T00:34:06ZRoberto BagnaraTorbjorn Granlund wrote:
<div class='shrinkable-quote'><br>> Roberto Bagnara <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23150639&i=0" target="_top" rel="nofollow">bagnara@...</a>> writes:
<br>>
<br>> > Speedups:
<br>> > * Vastly improved assembly code for x86-64 processors from AMD and Intel.
<br>>
<br>> I have run a couple of application programs based on the Parma Polyhedra
<br>> Library (PPL), which heavily depends on GMP. On an AMD Opteron 2384 "Shanghai"
<br>> I got the following running times (best run out of 10):
<br>>
<br>> Application A Application B
<br>>
<br>> GMP 4.2.4 GMP 4.3.0 GMP 4.2.4 GMP 4.3.0
<br>>
<br>> 238 s 187 s 34.2 s 34.8 s
<br>>
<br>> On an Intel Core2 Q9400, instead, I got:
<br>>
<br>> Application A Application B
<br>>
<br>> GMP 4.2.4 GMP 4.3.0 GMP 4.2.4 GMP 4.3.0
<br>>
<br>> 339 s 213 s 29.8 s 28.9 s
<br>>
<br>> You get less speedup than I expect to be typical (and a very slight
<br>> slowdown in one case).
<br>>
<br>> I am curious what GMP operations application B performs. Profile runs
<br>> for both GMP versions would be helpful.
</div><br>Hi Torbjorn,
<br><br>I was in fact wrong. While the PPL is, generally speaking, heavily
<br>dependent on GMP, application B running time is dominated by non-GMP
<br>functions. For it, the most important GMP operation is __gmpn_popcount
<br>which consumes 12% of the running time.
<br>Thanks again,
<br><br> Roberto
<br><br>--
<br>Prof. Roberto Bagnara
<br>Computer Science Group
<br>Department of Mathematics, University of Parma, Italy
<br><a href="http://www.cs.unipr.it/~bagnara/" target="_top" rel="nofollow">http://www.cs.unipr.it/~bagnara/</a><br>mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23150639&i=1" target="_top" rel="nofollow">bagnara@...</a>
<br>_______________________________________________
<br>gmp-discuss mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23150639&i=2" target="_top" rel="nofollow">gmp-discuss@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-discuss" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-discuss</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Discuss-f1661.html" embed="fixTarget[1661]" target="_top" >Gnu - GMP - Discuss</a></p>tag:old.nabble.com,2006:post-23104879Re: inline errors with gmp 4.2.4 (on Mac) - solution2009-04-17T11:41:32Z2009-04-17T11:41:32ZWade Williams<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Joubert,<div><br></div><div>I just got around to testing this and it worked perfectly. Thanks so much for the suggestion!</div><div><br></div><div>As you suggested, I just changed the C Language Dialect to gnu89.</div><div><br></div><div>Wade</div><div><br><div><div>On Mar 17, 2009, at 7:38 PM, Joubert Nel wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Wade,</div><div><br></div><div>I have also been struggling with the <b>duplicate symbol ___gmp_abs problem</b> for the last day. But finally found a solution.</div><div>The problem for me was not compiling GMP itself (I use Fink / MacPorts), but rather my inclusion of its header file (gmp.h) - same error message as you.</div><div><br></div><div>The following Build settings for my Target in XCode did the trick:</div><div>- C/C++ Compiler Version = <b>GCC 4.2</b></div><div>- C Language Dialect = <b>C99 [-std=c99]</b></div><div>- Other C flags: <b>-fgnu89-inline</b></div><div><br></div><div>Alternatively, if you simply compile with C Language Dialect set to 89 (instead of 99), that should work too.</div><div><br></div><div>Joubert</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><span class="Apple-style-span" style="font-size: 15px; "><h1>inline errors with gmp 4.2.4</h1><b>Wade Williams</b> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23104879&i=0" target="_top" rel="nofollow">...</a><br><i>Tue Jan 20 16:28:33 CET 2009</i><div><br class="webkit-block-placeholder"></div><ul><li>Previous message: <a href="http://gmplib.org/list-archives/gmp-discuss/2009-January/003520.html" target="_top" rel="nofollow">GMP can't handle leading plus sign?</a></li><li>Next message: <a href="http://gmplib.org/list-archives/gmp-discuss/2009-January/003523.html" target="_top" rel="nofollow">gmp 4.2.4 - mpf_add two large negative floats - strange result</a></li><li><b>Messages sorted by:</b> <a href="http://gmplib.org/list-archives/gmp-discuss/2009-January/date.html#3522" target="_top" rel="nofollow">[ date ]</a> <a href="http://gmplib.org/list-archives/gmp-discuss/2009-January/thread.html#3522" target="_top" rel="nofollow">[ thread ]</a> <a href="http://gmplib.org/list-archives/gmp-discuss/2009-January/subject.html#3522" target="_top" rel="nofollow">[ subject ]</a> <a href="http://gmplib.org/list-archives/gmp-discuss/2009-January/author.html#3522" target="_top" rel="nofollow">[ author ]</a></li></ul><hr><pre>I've got one more problem with gmp for which I hope there's a solution.
I have spent long hours googling on this subject and trying the
various suggestions presented, but so far none have worked. I also
have emailed Apple's XCode mailing list, hoping to find a solution
without bothering the gmp community, but was unsuccessful. I also
searched through the last year of archives on this list.
When I compile gmp 4.2.4 (32-bit) on OS X 10.5.4 I get:
duplicate symbol ___gmpz_abs in /Users/wwilliam/Development/code/
project/build/Debug/libcrypt.a(crypt.o) and /Users/wwilliam/
Development/code/project/build/Debug/libcrypt.a(rsa.o)
My understanding from my searches is that this due to a bug in Apple's
inline implementation.
Defining __GMP_FORCE_mpz_abs got rid of this error, but then the same
error occurred with with __gmpz_fits_uint_p. Defining
__GMP_FORCE_mpz_fits_uint_p did not resolve that error, leading me to
worry that I didn't truly understand the issue and changing things at
random was not a good idea.
I'm hoping this issue has been seen before and there's a simple
solution that I'm just missing.
Thanks,
Wade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <a href="http://swox.com/list-archives/gmp-discuss/attachments/20090120/68ff3cb0/attachment.html" target="_top" rel="nofollow">http://swox.com/list-archives/gmp-discuss/attachments/20090120/68ff3cb0/attachment.html</a>
</pre><hr><div><br class="webkit-block-placeholder"></div><ul><li>Previous message: <a href="http://gmplib.org/list-archives/gmp-discuss/2009-January/003520.html" target="_top" rel="nofollow">GMP can't handle leading plus sign?</a></li><li>Next message: <a href="http://gmplib.org/list-archives/gmp-discuss/2009-January/003523.html" target="_top" rel="nofollow">gmp 4.2.4 - mpf_add two large negative floats - strange result</a></li><li><b>Messages sorted by:</b> <a href="http://gmplib.org/list-archives/gmp-discuss/2009-January/date.html#3522" target="_top" rel="nofollow">[ date ]</a> <a href="http://gmplib.org/list-archives/gmp-discuss/2009-January/thread.html#3522" target="_top" rel="nofollow">[ thread ]</a> <a href="http://gmplib.org/list-archives/gmp-discuss/2009-January/subject.html#3522" target="_top" rel="nofollow">[ subject ]</a> <a href="http://gmplib.org/list-archives/gmp-discuss/2009-January/author.html#3522" target="_top" rel="nofollow">[ author ]</a></li></ul><hr><a href="http://swox.com/mailman/listinfo/gmp-discuss" target="_top" rel="nofollow">More information about the gmp-discuss mailing list</a></span></div></div>_______________________________________________<br>gmp-discuss mailing list<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23104879&i=1" target="_top" rel="nofollow">gmp-discuss@...</a><br>http://gmplib.org/mailman/listinfo/gmp-discuss<br></blockquote></div><br></div></body></html><br />_______________________________________________
<br>gmp-discuss mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23104879&i=2" target="_top" rel="nofollow">gmp-discuss@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-discuss" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-discuss</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Discuss-f1661.html" embed="fixTarget[1661]" target="_top" >Gnu - GMP - Discuss</a></p>tag:old.nabble.com,2006:post-23064561Re: GMP 4.3.0 released2009-04-15T11:32:56Z2009-04-15T11:32:56ZTorbjorn Granlund-6Roberto Bagnara <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23064561&i=0" target="_top" rel="nofollow">bagnara@...</a>> writes:
<br><br> > Speedups:
<br> > * Vastly improved assembly code for x86-64 processors from AMD and Intel.
<br>
<br> I have run a couple of application programs based on the Parma Polyhedra
<br> Library (PPL), which heavily depends on GMP. On an AMD Opteron 2384 "Shanghai"
<br> I got the following running times (best run out of 10):
<br>
<br> Application A Application B
<br>
<br> GMP 4.2.4 GMP 4.3.0 GMP 4.2.4 GMP 4.3.0
<br>
<br> 238 s 187 s 34.2 s 34.8 s
<br>
<br> On an Intel Core2 Q9400, instead, I got:
<br>
<br> Application A Application B
<br>
<br> GMP 4.2.4 GMP 4.3.0 GMP 4.2.4 GMP 4.3.0
<br>
<br> 339 s 213 s 29.8 s 28.9 s
<br>
<br>You get less speedup than I expect to be typical (and a very slight
<br>slowdown in one case).
<br><br>I am curious what GMP operations application B performs. Profile runs
<br>for both GMP versions would be helpful.
<br><br> > Misc:
<br> > * The gmp_version variable now always contains three parts. For this
<br> > release, it is "4.3.0".
<br>
<br> Aaargh! This broke our GMP detection procedure. Moreover,
<br> PPL 0.10.1 was released only a few hours before the release of
<br> GMP 4.3.0. I guess now we have no choice but release PPL 0.10.2
<br> with a revised GMP detection procedure.
<br><br>I am sorry about that! I think version GMP detection will be simpler
<br>with the new scheme, but this slight incompatibility will bite during a
<br>transitional period.
<br>
<br> Was a release candidate made available and announced somewhere?
<br><br>No, we did only internal testing this time, since our testing has been
<br>much extended.
<br><br>--
<br>Torbjörn
<br>_______________________________________________
<br>gmp-discuss mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23064561&i=1" target="_top" rel="nofollow">gmp-discuss@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-discuss" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-discuss</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Discuss-f1661.html" embed="fixTarget[1661]" target="_top" >Gnu - GMP - Discuss</a></p>tag:old.nabble.com,2006:post-23065541Re: GMP 4.3.0 released2009-04-15T11:21:35Z2009-04-15T11:21:35ZDennis Clarke-2<div class='shrinkable-quote'><br>> Torbjorn Granlund wrote:
<br>>> It is my great pleasure to announce the availability a new major release
<br>>> of
<br>>> the GNU Multiple Precision Arithmetic Library (GMP). The new release is
<br>>> identified as 4.3.0.
<br>>
<br>> Hi Torbjorn,
<br>>
<br>> congratulations and thank you for the new release.
<br>>
</div><br>With the most minor tweak it builds fine on Solaris :
<br><br>ABI=32
<br><br>$ ls .libs/lib*
<br>.libs/libgmp.a .libs/libgmp.so.3 .libs/libgmpxx.lai
<br>.libs/libgmp.la .libs/libgmp.so.3.5.0 .libs/libgmpxx.so
<br>.libs/libgmp.lai .libs/libgmpxx.a .libs/libgmpxx.so.4
<br>.libs/libgmp.so .libs/libgmpxx.la .libs/libgmpxx.so.4.1.0
<br>$
<br>$
<br>$ file .libs/libgmp.so.3.5.0
<br>.libs/libgmp.so.3.5.0: ELF 32-bit MSB dynamic lib SPARC Version 1,
<br>dynamically linked, not stripped
<br>$ file .libs/libgmpxx.so.4.1.0
<br>.libs/libgmpxx.so.4.1.0: ELF 32-bit MSB dynamic lib SPARC Version
<br>1, dynamically linked, not stripped
<br><br>and ABI=64
<br><br>$ file .libs/libgmp.so.3.5.0
<br>.libs/libgmp.so.3.5.0: ELF 64-bit MSB dynamic lib SPARCV9 Version 1,
<br>dynamically linked, not stripped
<br>$ file .libs/libgmpxx.so.4.1.0
<br>.libs/libgmpxx.so.4.1.0: ELF 64-bit MSB dynamic lib SPARCV9 Version
<br>1, dynamically linked, not stripped
<br><br>All tests pass for libgmp.so.3.5.0 however I have to get in and manually
<br>run the tests for the cxx libs.
<br><br>Dennis Clarke
<br><a href="http://www.blastwave.org" target="_top" rel="nofollow">http://www.blastwave.org</a><br><br><br>_______________________________________________
<br>gmp-discuss mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23065541&i=0" target="_top" rel="nofollow">gmp-discuss@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-discuss" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-discuss</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Discuss-f1661.html" embed="fixTarget[1661]" target="_top" >Gnu - GMP - Discuss</a></p>tag:old.nabble.com,2006:post-23064010Re: GMP 4.3.0 released2009-04-15T10:59:57Z2009-04-15T10:59:57ZRoberto BagnaraTorbjorn Granlund wrote:
<br>> It is my great pleasure to announce the availability a new major release of
<br>> the GNU Multiple Precision Arithmetic Library (GMP). The new release is
<br>> identified as 4.3.0.
<br><br>Hi Torbjorn,
<br><br>congratulations and thank you for the new release.
<br><br><br>> Speedups:
<br>> * Vastly improved assembly code for x86-64 processors from AMD and Intel.
<br><br>I have run a couple of application programs based on the Parma Polyhedra
<br>Library (PPL), which heavily depends on GMP. On an AMD Opteron 2384 "Shanghai"
<br>I got the following running times (best run out of 10):
<br><br> Application A Application B
<br><br> GMP 4.2.4 GMP 4.3.0 GMP 4.2.4 GMP 4.3.0
<br><br> 238 s 187 s 34.2 s 34.8 s
<br><br>On an Intel Core2 Q9400, instead, I got:
<br><br> Application A Application B
<br><br> GMP 4.2.4 GMP 4.3.0 GMP 4.2.4 GMP 4.3.0
<br><br> 339 s 213 s 29.8 s 28.9 s
<br><br><br>> Misc:
<br>> * The gmp_version variable now always contains three parts. For this
<br>> release, it is "4.3.0".
<br><br>Aaargh! This broke our GMP detection procedure. Moreover,
<br>PPL 0.10.1 was released only a few hours before the release of
<br>GMP 4.3.0. I guess now we have no choice but release PPL 0.10.2
<br>with a revised GMP detection procedure.
<br><br>Was a release candidate made available and announced somewhere?
<br>If so, I would like to subscribe the list for this kind of
<br>announcements.
<br>Thanks again,
<br><br> Roberto
<br><br>--
<br>Prof. Roberto Bagnara
<br>Computer Science Group
<br>Department of Mathematics, University of Parma, Italy
<br><a href="http://www.cs.unipr.it/~bagnara/" target="_top" rel="nofollow">http://www.cs.unipr.it/~bagnara/</a><br>mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23064010&i=0" target="_top" rel="nofollow">bagnara@...</a>
<br>_______________________________________________
<br>gmp-discuss mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23064010&i=1" target="_top" rel="nofollow">gmp-discuss@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-discuss" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-discuss</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Discuss-f1661.html" embed="fixTarget[1661]" target="_top" >Gnu - GMP - Discuss</a></p>tag:old.nabble.com,2006:post-23048552Re: Make error2009-04-14T14:30:18Z2009-04-14T14:30:18ZRyan Schmidt-59On Apr 13, 2009, at 21:29, Patrick Eisenmann wrote:
<br><br>> I encountered 3 main problems while trying to install GMP onto my
<br>> Macbook (OS 10.5.6).
<br>>
<br>> The first, if I try to make check in uncompressed library and that
<br>> library has a space character anywhere in its path, my make check
<br>> fails on the first set of tests. Moving to a lower directory fixed
<br>> this.
<br><br>Spaces in the path is a general problem for most UNIX software. I
<br>once reported this as a bug to the people who make the autotools
<br>software, and they said it is not a bug, it is a user error, and they
<br>will not fix it. Therefore to save yourself from running into these
<br>problems, I recommend you use paths that do not contain spaces.
<br><br><br>> Second, if you accidentally make check before make, it fails
<br>> inexplicably and reports problems that shouldn't exist. Using make
<br>> clean, then starting again from the beginning fixed this.
<br><br>I'll let the gmp people respond to this; it sounds like a bug. (Some
<br>missing dependency in the makefile?)
<br><br><br>> Third, make install failed due to permission errors. Using sudo
<br>> make install (and having the root password) fixed this.
<br><br>That's expected, since by default it wants to install into /usr/local
<br>which requires administrator privilege to modify. If you want to
<br>install to a location that doesn't require administrator privilege,
<br>specify it at configure time using the --prefix=/wherever switch.
<br><br><br><br>_______________________________________________
<br>gmp-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23048552&i=0" target="_top" rel="nofollow">gmp-bugs@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-bugs" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Bugs-f1659.html" embed="fixTarget[1659]" target="_top" >Gnu - GMP - Bugs</a></p>tag:old.nabble.com,2006:post-23034376Make error2009-04-13T19:29:05Z2009-04-13T19:29:05ZPatrick EisenmannHi,<br>I encountered 3 main problems while trying to install GMP onto my Macbook (OS 10.5.6).<br><br>The first, if I try to make check in uncompressed library and that library has a space character anywhere in its path, my make check fails on the first set of tests. Moving to a lower directory fixed this.<br>
Second, if you accidentally make check before make, it fails inexplicably and reports problems that shouldn't exist. Using make clean, then starting again from the beginning fixed this.<br>Third, make install failed due to permission errors. Using sudo make install (and having the root password) fixed this.<br clear="all">
<br>-- <br>Patrick Eisenmann<br>Undergrad Computer Science<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23034376&i=0" target="_top" rel="nofollow">peisenmann@...</a>
<br />_______________________________________________
<br>gmp-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=23034376&i=1" target="_top" rel="nofollow">gmp-bugs@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-bugs" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Bugs-f1659.html" embed="fixTarget[1659]" target="_top" >Gnu - GMP - Bugs</a></p>tag:old.nabble.com,2006:post-22904410Re: none2009-04-06T01:35:00Z2009-04-06T01:35:00ZTorbjorn Granlund-2Wayne Crawford <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=22904410&i=0" target="_top" rel="nofollow">crawford@...</a>> writes:
<br><br> In your gmp.info document, under "Known Build Problems", section MacOS
<br> X, it would be clearer if you wrote ('configure --disable-shared')
<br> instead of just ('--disable-shared')
<br>
<br> In any case, whether or not I use "configure --disable-shared" before
<br> running "make", I get the same error on "make check":
<br>
<br>Do you start with a pristing build directory each time (or issue "make
<br>distclean")?
<br><br>--
<br>Torbjörn
<br>_______________________________________________
<br>gmp-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=22904410&i=1" target="_top" rel="nofollow">gmp-bugs@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-bugs" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Bugs-f1659.html" embed="fixTarget[1659]" target="_top" >Gnu - GMP - Bugs</a></p>tag:old.nabble.com,2006:post-22904349Re: gmp-4.2.4 failures with Solaris 10 AMD64 and Studio Express 03/092009-04-06T01:30:54Z2009-04-06T01:30:54ZTorbjorn Granlund-2Dennis Clarke <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=22904349&i=0" target="_top" rel="nofollow">dclarke@...</a>> writes:
<br><br> >> Everything was going well until I ran make check.
<br> >
<br> > it seems to be a big-endian vs little-endian issue. Maybe the configure
<br> > script
<br> > was fooled by the combination Solaris - AMD64.
<br>
<br> Why would that be a problem? Solaris has been 64-bit on AMD64 for years.
<br>
<br>And GMP's configure should not have any problems with this particular
<br>combination.
<br><br> I just did a full re-compile again. No optimization and nothing fancy.
<br> Same code segfaults and dumps core over and over.
<br>
<br>How did you disable optimization? Some compilers are hard to persuade
<br>to not optimize.
<br><br>I tried gmp 4.2.4 on a Slowaris 11 (uname says 5.11 snv_105) system
<br>now, forcing it to use cc instead of gcc:
<br><br>tray$ cc -V
<br>cc: Sun Ceres C 5.10 SunOS_i386 2008/10/22
<br>usage: cc [ options] files. Use 'cc -flags' for details
<br><br>I started with:
<br><br>tray$ path-to-gmp-4.2.4/configure CC=cc --disable-static >&cfg.log
<br>tray$ gmake
<br>tray$ gmake check
<br><br>This failed because configure doesn't know how to put the compiler in
<br>64-bit mode. For sparc-slowris, one needs to pass an ISA option
<br>"-xarch=v9" for choosing ABI, very odd. But here the right option is
<br>apparently "-m64". GMP's configure doesn't know that. Let's therefore
<br>add it manually:
<br><br>tray$ path-to-gmp-4.2.4/configure CC="cc -m64" --disable-shared >&cfg.log
<br>tray$ gmake
<br>tray$ gmake check
<br><br>This worked. I also tried a shared build:
<br><br>tray$ path-to-gmp-4.2.4/configure CC="cc -m64" --disable-static >&cfg.log
<br>tray$ gmake
<br>tray$ gmake check
<br><br>This worked too.
<br><br> I'll try to focus on one test at a time and see if I can single step into
<br> this.
<br>
<br>Yes, I suppose you need to debug this. The odds are on a compiler (or
<br>assembler or linker) bug.
<br><br>--
<br>Torbjörn
<br>_______________________________________________
<br>gmp-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=22904349&i=1" target="_top" rel="nofollow">gmp-bugs@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-bugs" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Bugs-f1659.html" embed="fixTarget[1659]" target="_top" >Gnu - GMP - Bugs</a></p>tag:old.nabble.com,2006:post-22903803Re: gmp-4.2.4 failures with Solaris 10 AMD64 and Studio Express 03/092009-04-05T23:05:21Z2009-04-05T23:05:21ZDennis Clarke-2<br>>> Everything was going well until I ran make check.
<br>>
<br>> it seems to be a big-endian vs little-endian issue. Maybe the configure
<br>> script
<br>> was fooled by the combination Solaris - AMD64.
<br><br>Why would that be a problem? Solaris has been 64-bit on AMD64 for years.
<br><br>I just did a full re-compile again. No optimization and nothing fancy.
<br>Same code segfaults and dumps core over and over.
<br><br>$ ./tests/mpz/t-io_raw
<br>check_in: result wrong
<br> i=1 zeros=0 neg=0
<br> got_ret 5
<br> want_ret 5
<br> got =0x8100000000000000
<br> want =0x81
<br>Abort(coredump)
<br>$ find . -type f | grep core
<br>./tests/mpz/core.t-io_raw.isis_global_i86pc.16411:101.1238997336.20116
<br>./tests/mpz/core.t-import.isis_global_i86pc.16411:101.1238997336.20136
<br>./tests/mpz/core.t-export.isis_global_i86pc.16411:101.1238997337.20156
<br>./core.t-io_raw.isis_global_i86pc.16411:101.1238997763.20239
<br>$
<br><br>I can generate core files on demand and I am thinking I should go back and
<br>recompile such that I can single step into this until the fault occurs.
<br>There must be a way to find the root cause here.
<br><br>$ file ./tests/mpz/.libs/t-io_raw
<br>./tests/mpz/.libs/t-io_raw: ELF 64-bit LSB executable AMD64 Version 1
<br>[SSE2 SSE FXSR FPU], dynamically linked, not stripped
<br>$ ldd ./tests/mpz/.libs/t-io_raw
<br> libgmp.so.3 =>
<br>/export/medusa/dclarke/build/libgmp/i386/CXX/gmp-4.2.4-build-amd64/.libs/libgmp.so.3
<br> libthread.so.1 => /lib/64/libthread.so.1
<br> libc.so.1 => /lib/64/libc.so.1
<br> libm.so.2 => /lib/64/libm.so.2
<br><br>I have LD_LIBRARY_PATH set to find the correct libs.
<br><br>$ dbx ./tests/mpz/.libs/t-io_raw
<br>For information about new features see `help changes'
<br>To remove this message, put `dbxenv suppress_startup_message 7.7' in your
<br>.dbxrc
<br>Reading t-io_raw
<br>Reading ld.so.1
<br>Reading libgmp.so.3.4.4
<br>Reading libthread.so.1
<br>Reading libc.so.1
<br>(dbx) run
<br>Running: t-io_raw
<br>(process id 20265)
<br>check_in: result wrong
<br> i=1 zeros=0 neg=0
<br> got_ret 5
<br> want_ret 5
<br> got =0x8100000000000000
<br> want =0x81
<br>t@1 (l@1) signal ABRT (Abort) in __lwp_kill at 0xfffffd7fff27c94a
<br>0xfffffd7fff27c94a: __lwp_kill+0x000a: jae __lwp_kill+0x18 [
<br>0xfffffd7fff27c958, .+0xe ]
<br>(dbx) where
<br>current thread: t@1
<br>=>[1] __lwp_kill(0x1, 0x6, 0xffffffff89dde400, 0x3, 0x0, 0x0), at
<br>0xfffffd7fff27c94a
<br> [2] _thr_kill(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff275223
<br> [3] raise(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff221c39
<br> [4] abort(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fff2011c0
<br> [5] check_in(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x403b73
<br> [6] main(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x40462b
<br>(dbx) quit
<br>$
<br><br>I'll try to focus on one test at a time and see if I cna single step into
<br>this.
<br><br>Dennis
<br><br><br>_______________________________________________
<br>gmp-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=22903803&i=0" target="_top" rel="nofollow">gmp-bugs@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-bugs" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Bugs-f1659.html" embed="fixTarget[1659]" target="_top" >Gnu - GMP - Bugs</a></p>tag:old.nabble.com,2006:post-22888464Re: gmp-4.2.4 failures with Solaris 10 AMD64 and Studio Express 03/092009-04-04T15:25:19Z2009-04-04T15:25:19ZPaul Zimmermann> Everything was going well until I ran make check.
<br><br>it seems to be a big-endian vs little-endian issue. Maybe the configure script
<br>was fooled by the combination Solaris - AMD64.
<br><br>Paul Zimmermann
<br>_______________________________________________
<br>gmp-bugs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=22888464&i=0" target="_top" rel="nofollow">gmp-bugs@...</a>
<br><a href="http://gmplib.org/mailman/listinfo/gmp-bugs" target="_top" rel="nofollow">http://gmplib.org/mailman/listinfo/gmp-bugs</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---GMP---Bugs-f1659.html" embed="fixTarget[1659]" target="_top" >Gnu - GMP - Bugs</a></p>