On Sat, Jan 30, 2010 at 2:54 PM, Bill Hart wrote:
> I've placed an MPIR 1.3.1 which hopefully fixes this issue, here:
>
> http://www.mpir.org/mpir-1.3.1.tar.gz
>
> Let me know if there are further problems.
I confirmed that the problem existed in gmpy with 1.3.0 and is fixed in 1.3.1.
casevh
>
>
I've placed an MPIR 1.3.1 which hopefully fixes this issue, here:
http://www.mpir.org/mpir-1.3.1.tar.gz
Let me know if there are further problems.
Bill.
2010/1/30 Bill Hart :
> Hi Dan,
>
> Yes, there is a bug. The fix is to replace line 1130 of mpn/gcdext.c with:
>
> *s0size = 1 - (s0p[0] == 0)
Hi Dan,
Yes, there is a bug. The fix is to replace line 1130 of mpn/gcdext.c with:
*s0size = 1 - (s0p[0] == 0);
I will issue a service release shortly to fix this issue.
Can you let us know if this fixes your (other) program.
Bill.
2010/1/30 Bill Hart :
> Hi Dan,
>
> That definitely looks lik
Hi Dan,
That definitely looks like a bug. You are correct in that size should
be set to zero.
It's slightly bizarre in that we haven't altered mpz_gcdext, that I
recall. But we did modify mpn_gcdext, so I assume the bug is there.
I'll take a look.
Bill.
2010/1/30 Dan Grayson :
> #include
> #i
#include
#include
int main () {
mpz_t a,b,d,u,v;
mpz_init(a);
mpz_init(b);
mpz_init(d);
mpz_init(u);
mpz_init(v);
mpz_set_si(a,1);
mpz_set_si(b,2);
mpz_gcdext(d,u,v,a,b);
assert(!(u->_mp_size == 1 && u->_mp_d[0] == 0));
assert(!(v->_mp_size == 1 && v->_mp_d[0] == 0));
ret
I found another Ultrasparc2 which is set up correctly (same linux),
and the MPIR C++ tests pass no problems. So this confirms my belief
that gcc54 was just set up wrongly.
I'm going to close the longstanding ticket we have open for that, and
I'll just build on the other machine I have found, in fu
2010/1/30 Dr. David Kirkby :
> BTW, a 64-bit build of mpir 1.3.0 on an HP-C3600, running HP-UX 11.11B,
> results in the results shown below. This is with a PA-RISC processor - I do
> not have access to any of the newer Itanium machines.
>
> This is really good news, as an HP-UX port of Sage seems
If you don't want to change LD_LIBRARY_PATH, change LD_LIBRARY_PATH_64
as I explained.
It's this simple:
1) GCC NEEDS** complicated binaries to link against libgcc
(read the supplied references online or google it yourself)
2) Thus the linker NEEDS*** the path to the 64 bit libgc
Sorry, I pressed send before sanitising. I didn't intend to post the
expletives. Apologies for any offence.
I am just a bit frustrated at the moment, probably for reasons that
have nothing to do with this conversation, sorry.
Bill.
2010/1/30 Bill Hart :
> 2010/1/30 Dr. David Kirkby :
>> Bill Har
2010/1/30 Dr. David Kirkby :
> Bill Hart wrote:
>>
>> Cause of what David? MPIR 1.3.0 works absolutely fine on t2 if you set
>> the library paths correctly.
>
> I'm not convinced it should be necessary to set LD_LIBRARY_PATH like that.
> It is not with other 64-bit applications. But I may be mistak
Bill Hart wrote:
Cause of what David? MPIR 1.3.0 works absolutely fine on t2 if you set
the library paths correctly.
I'm not convinced it should be necessary to set LD_LIBRARY_PATH like that. It is
not with other 64-bit applications. But I may be mistaken
BTW, a 64-bit build of mpir 1.3.0 on
11 matches
Mail list logo
