On 29.03.2014 12:48, Bill Hart wrote:
All tests now pass on MinGW, MinGW64, Cygwin and Cygwin64. For the first
time ever!
Windows FTW! ;-)
The fix for issue #23 is incomplete though; you apparently missed the
patch to acinclude.m4:
--- src/acinclude.m4 2013-02-27 04:51:08.528733998 +0100
+++ src/acinclude.m4 2013-02-27 06:19:10.558735026 +0100
@@ -41,7 +41,7 @@
[[powerpc64-*-* | powerpc64le-*-* | powerpc620-*-* | powerpc630-*-* |
powerpc970-*-* | power[3-9]-*-*]])
define(X86_PATTERN,
-[[i?86*-*-* | k[5-8]*-*-* | pentium*-*-* | athlon-*-* | viac3*-*-*]])
+[[i?86*-*-* | k[5-8]*-*-* | pentium*-*-* | prescott-*-* | core-*-* |
athlon-*-* | viac3*-*-*]])
define(X86_64_PATTERN,
[[x86_64-*-* | netburst-*-* | netburstlahf-*-* | k8-*-* | k10-*-* |
k102-*-* | k103-*-* | core2-*-* | penryn-*-* | nehalem-*-* |
westmere-*-* | sandybridge-*-* | atom-*-* | nano-*-* | bobcat-*-* |
bulldozer-*-*]])
such that one still ends up with ABI="standard", an (almost) empty
MPN_PATH (just containing "generic") and incorrect / incomplete C- and
CXXFLAGS.
I have to admit I'm not sure whether I submitted the patches to the
autotools *source* files upstream last year; they're contained in the
Sage package (or nowadays the "package metadata"(?) for MPIR) though.
-leif
P.S.: In the long run, it may make sense to also have core-*-* and
prescott-*-* have their own gmp-mparam.h files (by adding some
subdirectories like you did for e.g. piledriver and bulldozer, and
prepending them to their MPN_PATH, although there's not yet specific
assembly code for these). My Prescott still doesn't get detected as
such (just as an ordinary Pentium 4), because cpuid.c considers every
model <=6 of family 15 a plain Pentium 4, although model 3 and model 4
are (or at least can be?) Prescotts as well. (Mine is a model 3.) But
that's a different story...
On 20 March 2014 00:44, Bill Hart <goodwillh...@googlemail.com
<mailto:goodwillh...@googlemail.com>> wrote:
Today I finally fixed mpn_mulmod_2expp1 to use the FFT wraparound
trick in the FFT region.
As mpn_mulmod_bnm1 uses this function, this means that GMP-ECM will
now be able to use MPIR more efficiently.
I think that much of our mulmod_2expp1 and mulmod_bnm1 code needs
rewriting, but this can wait until someone can do it properly.
I also added some tuning for the new division functions. I'm not
convinced it is picking the right thresholds, based on my own
timings. But it's coded correctly, so there's nothing I can do about
it. At least the division code doesn't seem to slow down with the
new tuning values.
Tomorrow I will add some tuning functions for the new GMP
combinatorics functions that we added. I will also fix a bug in the
fft tuning code which causes it to crash on some systems.
This should hopefully complete all the new features for MPIR 2.7 and
we can move on to closing all the open tickets for the release.
I have essentially until the end of next week to do as much as I
can, after which I will have to work weekends if it isn't done.
After tomorrow we will need to retune MPIR on as many platforms as
we can. Help with that would be appreciated.
By the way, after May 31st we'll lose access to about half the
machines we build on, due to one of the build farms closing down. So
if anyone has access to lots of heterogeneous hardware with linux,
git and recent gcc on it, please let us know.
Bill.
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.
