Actually, perhaps you wouldn't notice it on the bench at all. You
might notice it for things like mpz_get_ui which are inlined in gmp.h.
Bill.
2009/3/25 Bill Hart :
> The short answer is I don't know whether it causes a performance
> deficit. I also don't have a workaround at present.
>
> Howeve
The short answer is I don't know whether it causes a performance
deficit. I also don't have a workaround at present.
However this is a long standing issue, for which we have a ticket.
Obviously we've focused very much on the low hanging fruit performance
wise.
*If* it makes any difference, you w
I just tried compiling it on a brand new MacBook Pro (Core2) and it
works fine (make + make check) but I did see this in the output:
checking for inline... inline
configure: WARNING: mpir.h doesnt recognise compiler "inline", inlines
will be unavailable
So I'm not sure if that is a problem, will
There's been no word on the result of further testing in Sage, at this point.
I strongly suspect there will be no further candidates and this will
be final, but it seems logical to have the Sage developers test it as
part of their release cycle as the number of systems that it then gets
tested on
Just wondering what the status of 1.0.0 is. Are the changes people
have been talking about recently going to be rolled into 1.0.0 so we
will have an rc3 or will rc2 stay the same and become the official
1.0.0?
Jeff.
--~--~-~--~~~---~--~~
You received this message
Looks so far for me. I did some Itanium2 tests, core2 tests. Windows
builds are looking good, all the tests are there and working after
that last commit Brian did. I forgot how out of date Itanium
processors are now that 64bit x86 have hit the scene.
Intel Core2 Q9550 @ 3.4GHz (45nm, Family 6,
On Monday 16 March 2009 15:17:48 Bill Hart wrote:
> I checked the latest tarball and it seems ok now.
>
> Should also apply to the mpir-1.0 branch so that this change makes it
> into the service releases.
>
> Bill.
>
done
> 2009/3/16 Jason Moxham :
> > On Monday 16 March 2009 15:01:58 Bill Har
I checked the latest tarball and it seems ok now.
Should also apply to the mpir-1.0 branch so that this change makes it
into the service releases.
Bill.
2009/3/16 Jason Moxham :
>
> On Monday 16 March 2009 15:01:58 Bill Hart wrote:
>> I don't think that is right. svn does not preserve file perm
On Monday 16 March 2009 15:01:58 Bill Hart wrote:
> I don't think that is right. svn does not preserve file permissions.
>
> I've again tried to set the relevant flags in svn and updated the
> tarball. No idea whether it worked. But given that we've done this
> before, I think the make dist is the
I don't think that is right. svn does not preserve file permissions.
I've again tried to set the relevant flags in svn and updated the
tarball. No idea whether it worked. But given that we've done this
before, I think the make dist is the safest option.
Bill.
2009/3/16 Jason Moxham :
>
> On Mon
On Monday 16 March 2009 14:23:31 Bill Hart wrote:
> Hi Emmanuel,
>
> I'm sure we've turned it on numerous times before. I think our svn is
> broken wrt that feature.
>
> Probably we should have make dist chmod it. Perhaps Jason can arrange that.
>
can do , but I think I know how to fix
delete co
I've killed most of these and the others you mentioned.
We could probably write assembly code for Athlon 64 and nocona and
have separate directories for them, but we can add a ticket should we
decide to do this.
Bill.
2009/3/16 Jason Moxham :
>
>
> #16 is not applicable anymore as this refered
Hi Emmanuel,
I'm sure we've turned it on numerous times before. I think our svn is
broken wrt that feature.
Probably we should have make dist chmod it. Perhaps Jason can arrange that.
Bill.
2009/3/16 Emmanuel Thomé :
>
> On Mar 16, 1:38 am, Bill Hart wrote:
>> Here is the link to release cand
On Mar 16, 1:38 am, Bill Hart wrote:
> Here is the link to release candidate 2 tarball:
>
> http://sage.math.washington.edu/home/wbhart/mpir-1.0.tar.gz
config.guess has executable bit unset in this tarball, which seems
weird. Not too much of a problem, since install gets it right anyway.
svn pr
#43 Currently yasm builds unconditionally, whether it is needed or not.
This is not true , so we could kill this ticket , unless we want mpir
configure's and use a system wide yasm.
On Monday 16 March 2009 03:31:45 Jason Moxham wrote:
> New ticket
>
> tests/devel/try.c doesn't test all possi
New ticket
tests/devel/try.c doesn't test all possible overlaps for functions with 3 or
more source operands.
On Monday 16 March 2009 03:28:08 Jason Moxham wrote:
> #16 is not applicable anymore as this refered to the old AMD sqr-basecase
> #10 is done , for k10 ,core2 , no advantage for k8
>
#16 is not applicable anymore as this refered to the old AMD sqr-basecase
#10 is done , for k10 ,core2 , no advantage for k8
#2 doesn't apply for the current code as we dont jump into loops
#45 looks like you fixed , but I'm not sure
#63 is way out of date , we done it
#14 is mostly done
On
On Monday 16 March 2009 02:56:46 Bill Hart wrote:
> Probably tickets 87 and 95 no longer apply too, but we should check I
> guess.
#95 is definitely dead , mpir configure runs yasm configure so all make target
are there on all machines
>
> Bill.
>
> 2009/3/16 Bill Hart :
> > That would be it.
Probably tickets 87 and 95 no longer apply too, but we should check I guess.
Bill.
2009/3/16 Bill Hart :
> That would be it. I'll close the ticket and update the website.
>
> Bill.
>
> 2009/3/16 Jason Moxham :
>>
>> On Monday 16 March 2009 01:56:28 Bill Hart wrote:
>>> Nope, you are using it rig
That would be it. I'll close the ticket and update the website.
Bill.
2009/3/16 Jason Moxham :
>
> On Monday 16 March 2009 01:56:28 Bill Hart wrote:
>> Nope, you are using it right. It doesn't tell you more than we know.
>> Besides, you were the one who reported it.
>
> The closest one I could f
On Monday 16 March 2009 01:56:28 Bill Hart wrote:
> Nope, you are using it right. It doesn't tell you more than we know.
> Besides, you were the one who reported it.
The closest one I could find is this from thread "trunk distclean broken" from
29/12/08 , this has been fixed for a while
after d
Done.
2009/3/16 Bill Hart :
> I've updated the website http://www.mpir.org/ . Let me know of any
> errors or omissions.
>
> I'll now post to various lists.
>
> Bill.
>
> 2009/3/16 Bill Hart :
>> Nope, you are using it right. It doesn't tell you more than we know.
>> Besides, you were the one who
I've updated the website http://www.mpir.org/ . Let me know of any
errors or omissions.
I'll now post to various lists.
Bill.
2009/3/16 Bill Hart :
> Nope, you are using it right. It doesn't tell you more than we know.
> Besides, you were the one who reported it.
>
> Bill.
>
> 2009/3/16 Jason M
Nope, you are using it right. It doesn't tell you more than we know.
Besides, you were the one who reported it.
Bill.
2009/3/16 Jason Moxham :
>
> Ticket 110
> A generic build (no assembly, i.e. host=none) fails on x86_64 machines. This
> is a problem in configure.
>
> this is all it says , unle
Ticket 110
A generic build (no assembly, i.e. host=none) fails on x86_64 machines. This
is a problem in configure.
this is all it says , unless I'm using it wrong
On Monday 16 March 2009 01:22:07 Bill Hart wrote:
> Do you mean details of these issues? If so, there are trac tickets for
> each
Do you mean details of these issues? If so, there are trac tickets for
each of them. Below the red ones.
Bill.
2009/3/16 Jason Moxham :
>
> On Monday 16 March 2009 00:38:00 Bill Hart wrote:
>> Here is the link to release candidate 2 tarball:
>>
>> http://sage.math.washington.edu/home/wbhart/mpir
These all pass on i7
./configure --host=none && make -j 8 && make -j 8 check && make distclean
./configure --host=none-unknown-linux-gnu && make -j 8 && make -j 8 check &&
make distclean
./configure --build=none-unknown-linux-gnu && make -j 8 && make -j 8 check
&& make distclean
O
details?
2009/3/16 Jason Moxham :
>
> On Monday 16 March 2009 00:38:00 Bill Hart wrote:
>> Here is the link to release candidate 2 tarball:
>>
>> http://sage.math.washington.edu/home/wbhart/mpir-1.0.tar.gz
>>
>> and docs:
>>
>> http://sage.math.washington.edu/home/wbhart/mpir.pdf
>>
>> If no furt
On Monday 16 March 2009 00:38:00 Bill Hart wrote:
> Here is the link to release candidate 2 tarball:
>
> http://sage.math.washington.edu/home/wbhart/mpir-1.0.tar.gz
>
> and docs:
>
> http://sage.math.washington.edu/home/wbhart/mpir.pdf
>
> If no further bugs are found, this will become the final r
I've added what I think we should try, to:
http://trac.mpir.org/mpir_trac/ticket/112
Bill.
2009/2/5 Bill Hart :
> Well I wonder if one fixed the declaration to export the correct mpbsd
> function name and prototype whether it would just work.
>
> I also wonder if *we* did this or if it was alre
Well I wonder if one fixed the declaration to export the correct mpbsd
function name and prototype whether it would just work.
I also wonder if *we* did this or if it was already broken in GMP
4.2.1. To me it looks like it got messed up when the new gcd patches
were added.
Probably we should not
On Thursday 05 February 2009 20:18:29 Bill Hart wrote:
> 2009/2/5 :
> > On Wednesday 04 February 2009 19:54:03 Bill Hart wrote:
> >> Thanks. As soon as we release, it would be great if you could give it
> >> a go and we can issue a service release.
> >
> > Should I create a branch for it?
>
> I d
On Feb 5, 1:09 pm, Bill Hart wrote:
> 2009/2/5 mabshoff :
> > (a) I can give you access
> > (b) I can move the html and the tarball over there, too. I am busy for
> > the next couple hours, but I will try to squeeze it in.
>
> I would prefer to have access.
Yep, that is my preferred solutio
2009/2/5 mabshoff :
>
>
>
> On Feb 5, 12:18 pm, Bill Hart wrote:
>> 2009/2/5 :
>>
>>
>>
>> > On Wednesday 04 February 2009 19:54:03 Bill Hart wrote:
>> >> Thanks. As soon as we release, it would be great if you could give it
>> >> a go and we can issue a service release.
>>
>> > Should I create
>From my point of view it doesn't matter, as the intention will be to
fix this in the linux build as soon as possible.
We will treat this issue as urgent for MPIR 1.0.0 as well as getting
Jason's new assembly in.
Bill.
2009/2/5 Cactus :
>
>
>
> On Feb 5, 8:25 pm, Cactus wrote:
>> On Feb 5, 7:5
On Feb 5, 8:25 pm, Cactus wrote:
> On Feb 5, 7:56 pm, ja...@njkfrudils.plus.com wrote:
>
>
>
> > On Wednesday 04 February 2009 19:54:03 Bill Hart wrote:
>
> > > Thanks. As soon as we release, it would be great if you could give it
> > > a go and we can issue a service release.
>
> > Should I cr
On Feb 5, 12:18 pm, Bill Hart wrote:
> 2009/2/5 :
>
>
>
> > On Wednesday 04 February 2009 19:54:03 Bill Hart wrote:
> >> Thanks. As soon as we release, it would be great if you could give it
> >> a go and we can issue a service release.
>
> > Should I create a branch for it?
>
> I don't think
On Feb 5, 7:56 pm, ja...@njkfrudils.plus.com wrote:
> On Wednesday 04 February 2009 19:54:03 Bill Hart wrote:
>
> > Thanks. As soon as we release, it would be great if you could give it
> > a go and we can issue a service release.
>
> Should I create a branch for it?
>
> I cant do the windows bi
2009/2/5 :
>
> On Wednesday 04 February 2009 19:54:03 Bill Hart wrote:
>> Thanks. As soon as we release, it would be great if you could give it
>> a go and we can issue a service release.
>>
>
> Should I create a branch for it?
I don't think that is a good idea. We should release, then do this i
On Wednesday 04 February 2009 19:54:03 Bill Hart wrote:
> Thanks. As soon as we release, it would be great if you could give it
> a go and we can issue a service release.
>
Should I create a branch for it?
I cant do the windows bits , Brian ?
I dont do C++ , and I dont know how comprehensive th
Thanks. As soon as we release, it would be great if you could give it
a go and we can issue a service release.
Bill.
2009/2/4 :
>
> On Wednesday 04 February 2009 18:35:24 Bill Hart wrote:
>> Hi Mariah,
>>
>> 2009/2/4 Mariah :
>> > Bill,
>> >
>> > On Feb 4, 12:25 am, Bill Hart wrote:
>> >> I ha
On Wednesday 04 February 2009 18:35:24 Bill Hart wrote:
> Hi Mariah,
>
> 2009/2/4 Mariah :
> > Bill,
> >
> > On Feb 4, 12:25 am, Bill Hart wrote:
> >> I have placed a tarball here:
> >>
> >> http://sage.math.washington.edu/home/wbhart/mpir-0.9.0.tar.gz
> >
> > Some quick observations -
> >
> > 1.
Regarding 1, this is merely because of the way that mpir and yasm (the
assembler used in mpir - which is distributed with it) are chained
together on x86. The mpir make triggers the yasm configure and make.
This was a hack and no one seems to know how to chain two packages
together so that somethi
Hi Mariah,
2009/2/4 Mariah :
>
> Bill,
>
> On Feb 4, 12:25 am, Bill Hart wrote:
>> I have placed a tarball here:
>>
>> http://sage.math.washington.edu/home/wbhart/mpir-0.9.0.tar.gz
>>
>
> Some quick observations -
>
> 1. It looks like you have to build in the source tree. Many software
> packag
Bill,
On Feb 4, 12:25 am, Bill Hart wrote:
> I have placed a tarball here:
>
> http://sage.math.washington.edu/home/wbhart/mpir-0.9.0.tar.gz
>
Some quick observations -
1. It looks like you have to build in the source tree. Many software
packages let you have an object directory separate from
On Feb 3, 9:25 pm, Bill Hart wrote:
Hi Bill,
> I have placed a tarball here:
>
> http://sage.math.washington.edu/home/wbhart/mpir-0.9.0.tar.gz
>
> It will become the final version of MPIR if no further build failures
> are reported. Testing has not occurred on SkyNet yet. I would
> appreciate
I have placed a tarball here:
http://sage.math.washington.edu/home/wbhart/mpir-0.9.0.tar.gz
It will become the final version of MPIR if no further build failures
are reported. Testing has not occurred on SkyNet yet. I would
appreciate volunteers who have access (./configure; make; make check
is
Actually, I just committed a fix for a bug which would definitely
cause at least the first few of the errors above. I had a screwed up
regular expression in configure.in (I used a very simplistic regexp
tutorial and it was wrong in this situation).
Are you able to try again.
Bill.
2009/1/31 Bil
Hi Case,
thanks for checking this out. Can you send me a copy of the fat.h that
it generates. Perhaps there is some clue.
Bill.
2009/1/31 Case Vanhorsen :
>
> On 1/30/09, Bill Hart wrote:
>>
>> 2009/1/30 Case Vanhorsen :
>> >
>> > On Fri, Jan 30, 2009 at 4:07 AM, Bill Hart
>> > wrote:
>> >>
On 1/30/09, Bill Hart wrote:
>
> 2009/1/30 Case Vanhorsen :
> >
> > On Fri, Jan 30, 2009 at 4:07 AM, Bill Hart
> > wrote:
> >>
> >> 2009/1/30 Case Vanhorsen :
> >>>
> >>> On 1/29/09, Bill Hart wrote:
>
> Case,
>
> thank you, that would be very helpful.
>
> I have
2009/1/30 Case Vanhorsen :
>
> On Fri, Jan 30, 2009 at 4:07 AM, Bill Hart
> wrote:
>>
>> 2009/1/30 Case Vanhorsen :
>>>
>>> On 1/29/09, Bill Hart wrote:
Case,
thank you, that would be very helpful.
I have just finished building and testing MPIR on cygwin. Apart fro
On Fri, Jan 30, 2009 at 4:07 AM, Bill Hart wrote:
>
> 2009/1/30 Case Vanhorsen :
>>
>> On 1/29/09, Bill Hart wrote:
>>>
>>> Case,
>>>
>>> thank you, that would be very helpful.
>>>
>>> I have just finished building and testing MPIR on cygwin. Apart from a
>>> warning about undefined symbols in t
>
> I was able to work around the demos issue by using "touch *.c *.h" in
> the demos/calc directory. If you do that before you create the
> tarball, it should work.
>
Excellent! I had wondered about that. I will make a script for
generating tarballs for mpir. It will touch these files, remove .s
2009/1/30 Case Vanhorsen :
>
> On 1/29/09, Bill Hart wrote:
>>
>> Case,
>>
>> thank you, that would be very helpful.
>>
>> I have just finished building and testing MPIR on cygwin. Apart from a
>> warning about undefined symbols in the library (it didn't specify what
>> they were), it built and p
It is possible that the pentium code is broken. But I don't know
anyone who has one to try it out. I'm not overly worried as I'm doubt
our door is going to be knocked down by people trying to run MPIR on
old pentiums.
Obviously we'd like to hear from anyone who needs it and it doesn't
work for th
On 1/29/09, Bill Hart wrote:
>
> Case,
>
> thank you, that would be very helpful.
>
> I have just finished building and testing MPIR on cygwin. Apart from a
> warning about undefined symbols in the library (it didn't specify what
> they were), it built and passed make check just fine, even with
>
On Friday 30 January 2009 04:11:04 Bill Hart wrote:
> For this one I'm going to take a wild stab and guess that the clztab
> is wrong when you specify --host=586 on an Athlon, or there's some
> issue with arithmetic shifts.
>
host=pentiummmx passes
Do we still test on a real plain pentium? , if
On Friday 30 January 2009 04:07:04 Bill Hart wrote:
> I'm not sure. Who would select --host=386 on an athlon?
>
I did :)
> Also, the symbol that it says is missing, doesn't seem to exist
> anywhere in MPIR. It's probably something to do with the kernel or
> compiler on that machine.
>
Yeah , yo
2009/1/30 :
>
> On Thursday 29 January 2009 17:56:47 Bill Hart wrote:
>> The fat binary support on x86_64 is now fixed.
>
> Nice one
>
>>
>> I fixed the issue with fat binaries on x86_64 machines with ABI = 32.
>> Hopefully this also fixes it for cygwin and mingw. But it takes over
>> 1.5 hours t
For this one I'm going to take a wild stab and guess that the clztab
is wrong when you specify --host=586 on an Athlon, or there's some
issue with arithmetic shifts.
It's not clear to me that this is a meaningful failure.
If any of these machines fail without specifying a host different to
the o
I'm not sure. Who would select --host=386 on an athlon?
Also, the symbol that it says is missing, doesn't seem to exist
anywhere in MPIR. It's probably something to do with the kernel or
compiler on that machine.
Bill.
2009/1/30 :
>
> On Friday 30 January 2009 03:13:25 ja...@njkfrudils.plus.co
On Friday 30 January 2009 03:22:28 ja...@njkfrudils.plus.com wrote:
> On Friday 30 January 2009 03:13:25 ja...@njkfrudils.plus.com wrote:
> > On Thursday 29 January 2009 17:56:47 Bill Hart wrote:
> > > The fat binary support on x86_64 is now fixed.
> >
> > Nice one
> >
> > > I fixed the issue with
On Friday 30 January 2009 03:13:25 ja...@njkfrudils.plus.com wrote:
> On Thursday 29 January 2009 17:56:47 Bill Hart wrote:
> > The fat binary support on x86_64 is now fixed.
>
> Nice one
>
> > I fixed the issue with fat binaries on x86_64 machines with ABI = 32.
> > Hopefully this also fixes it f
On Thursday 29 January 2009 17:56:47 Bill Hart wrote:
> The fat binary support on x86_64 is now fixed.
Nice one
>
> I fixed the issue with fat binaries on x86_64 machines with ABI = 32.
> Hopefully this also fixes it for cygwin and mingw. But it takes over
> 1.5 hours to build under cygwin (make
Case,
thank you, that would be very helpful.
I have just finished building and testing MPIR on cygwin. Apart from a
warning about undefined symbols in the library (it didn't specify what
they were), it built and passed make check just fine, even with
--enable-fat.
With regard to the demos issue
Bill,
I can test a mingw32 build this evening. I just need to work around
the demos issue. I'll compile on a few other platforms, too.
Case
On Thu, Jan 29, 2009 at 9:56 AM, Bill Hart wrote:
>
> The fat binary support on x86_64 is now fixed.
>
> I fixed the issue with fat binaries on x86_64 ma
66 matches
Mail list logo
