MPIR-2.5.0-rc1 released
Jason
MPIR-2.5.0-rc1 is released for testing here
http://www.mpir.org/mpir-2.5.0-rc1.tar.bz2
The main changes are , very briefly and incomplete
new assembly code
fat builds more effiecent on x64
removed ancient/obsolete stuff and cleanups
new python windows build script
faster GCD code (Thanks GMP)
update yasm , clears up cygwin error
improved prime tests
The manual has not been updated to reflect the above yet and the news files etc
,hopefully I'll do it in the next few days but feel free to ask on the list.
Have fun
The MPIR Team
Jason
Hi , I've run most of the tests and the only new errors so far are some badly
installed g++'s . I had to update the tuning params for 32 sparc as they don't
tune properly for some reason on that arch . rc2 will just contain that change ,
and I'll try to modify the test scripts to ignore the know bad cases so we can
do more tests , as the scripts stop at the first error.
Jason
David Cleaver
On 12/5/2011 12:32 PM, Jason wrote:
> Hi
>
> MPIR-2.5.0-rc1 is released for testing here
>
> http://www.mpir.org/mpir-2.5.0-rc1.tar.bz2
I wanted to let you know that, when using msys/mingw64, 'make check' gets
through almost all tests successfully until misc/t-printf. It fails here due to
the fact that mingw64 does not print posix modifiers by default. A special
define needs to be used in order to get this to succeed. Here is the error message:
PASS: t-locale.exe
FAIL: t-printf.exe
PASS: t-scanf.exe
=============================================================
1 of 3 tests failed
See tests/misc/test-suite.log
Please report to http://groups.google.co.uk/group/mpir-devel/
=============================================================
When running t-printf.exe by itself, it says:
gmp_vsprintf wrong
fmt |%Mu|
got |4294967295|
want |8589934591|
got_len 10
want_len 10
The %Mu format is translated into %llu, the posix modifier to print unsigned
long long vars. However, without the mingw64 specific define in place, it just
prints out the lower 32 bits, and thus fails this test. I've described this in
detail on the GMP mailing list, which you can see here:
http://gmplib.org/list-archives/gmp-bugs/2011-June/002260.html
To reiterate here what I mentioned there, if, after running configure, I add the
following to the bottom of config.h:
#ifdef __MINGW64__
#define __USE_MINGW_ANSI_STDIO 1
#endif
Then run 'make', and then run 'make check', t-printf passes, and therefore ALL
tests pass, in this msys/mingw64 environment.
Is there any interest in applying a patch to fix this issue with the mingw64
compiler? I think the configure script would have to check for the mingw64
compiler, and then add this special define at the end of config.h so that 'make
check' will pass for mingw64 users. However, I don't know how to change the
configure script to do this. In any event, I wanted to let you know what I've
come across in my environment. Thanks again for all the work you do in making
MPIR very fast on Windows x64 systems.
-David C.
Sisyphus
----- Original Message -----
From: "David Cleaver"
> I wanted to let you know that, when using msys/mingw64, 'make check' gets
> through almost all tests successfully until misc/t-printf. It fails here
> due to the fact that mingw64 does not print posix modifiers by default. A
> special define needs to be used in order to get this to succeed. Here is
> the error message:
> PASS: t-locale.exe
> FAIL: t-printf.exe
> PASS: t-scanf.exe
No such failure for me using the same tools.
I've a notion that configure checks to see which modifiers are permitted
unless it thinks it's doing a cross-compilation. (Or was that mpfr ? ... not
sure now.)
What was your configure command ?
I used:
./configure --prefix=C:/_64/mpir --disable-shared --enable-static --enable-gmpcompat
LDFLAGS=-L/c/_64/mpir/lib CPPFLAGS=-I/c/_64/mpir/include
CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++
AR=x86_64-w64-mingw32-ar LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm
RANLIB=x86_64-w64-mingw32-ranlib OBJDUMP=x86_64-w64-mingw32-objdump
STRIP=x86_64-w64-mingw32-strip
(I think there's a few switches in there that aren't really necessary.)
Cheers,
Rob
David Cleaver
On 12/14/2011 10:51 PM, Sisyphus wrote:
>
> ----- Original Message ----- From: "David Cleaver"
>> FAIL: t-printf.exe
>> PASS: t-scanf.exe
>
> No such failure for me using the same tools.
>
> I've a notion that configure checks to see which modifiers are permitted unless
> it thinks it's doing a cross-compilation. (Or was that mpfr ? ... not sure now.)
> What was your configure command ?
>
> I used:
>
> ./configure --prefix=C:/_64/mpir --disable-shared --enable-static
> --enable-gmpcompat LDFLAGS=-L/c/_64/mpir/lib CPPFLAGS=-I/c/_64/mpir/include
> CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ AR=x86_64-w64-mingw32-ar
> LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm
> RANLIB=x86_64-w64-mingw32-ranlib OBJDUMP=x86_64-w64-mingw32-objdump
> STRIP=x86_64-w64-mingw32-strip
>
> (I think there's a few switches in there that aren't really necessary.)
>
> Cheers,
> Rob
The configure line that I used was:
./configure --build=penryn-w64-mingw32 --host=penryn-w64-mingw32 --enable-gmpcompat
I can try yours later tonight to see if I get the same results as you.
-David C.
Sisyphus
----- Original Message -----
From: "David Cleaver"
>> ./configure --prefix=C:/_64/mpir --disable-shared --enable-static
>> --enable-gmpcompat LDFLAGS=-L/c/_64/mpir/lib
>> CPPFLAGS=-I/c/_64/mpir/include
>> CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++
>> AR=x86_64-w64-mingw32-ar
>> LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm
>> RANLIB=x86_64-w64-mingw32-ranlib OBJDUMP=x86_64-w64-mingw32-objdump
>> STRIP=x86_64-w64-mingw32-strip
> The configure line that I used was:
>
> ./configure --build=penryn-w64-mingw32 --host=penryn-w64-mingw32 --enable-gmpcompat
Yes - when configure sees the '--build' and '--host' arguments, it will
decide that this is a cross-compilation and skip the checking of permissible
modifiers - thereby bringing about the failures that you see. (Of course,
that's only if I'm right about this :-)
> I can try yours later tonight to see if I get the same results as you.
I use the MinGW64 cross-compiler, where the names of the executables are all
prefixed with 'x86_64-w64-mingw32-'. That is, instead of 'gcc.exe' I have
'x86_64-w64-mingw32-gcc.exe', etc., etc.
If you're not using the cross-compiler, then that command won't work.
I think you probably just need to build without those --build and --host
options.
Does simply './configure --enable-gmpcompat' work ?
You might need to additionally specify 'ABI=64' - that's if configure
doesn't reach that conclusion by itself.
Cheers,
Rob
David Cleaver
On 12/15/2011 5:47 PM, Sisyphus wrote:
> I think you probably just need to build without those --build and --host options.
>
> Does simply './configure --enable-gmpcompat' work ?
> You might need to additionally specify 'ABI=64' - that's if configure doesn't
> reach that conclusion by itself.
>
> Cheers,
> Rob
>
I was surprised to find that yes './configure --enable-gmpcompat' works for me,
and it decided on:
configure:3022: checking build system type
configure:3036: result: core2-w64-mingw32
configure:3056: checking host system type
configure:3069: result: core2-w64-mingw32
This never worked for me with GMP (it kept picking i686) so I didn't think to
try it here. Thanks for reminding me to check that.
However, I still get the problem with the t-printf test failing saying:
PASS: t-locale.exe
FAIL: t-printf.exe
PASS: t-scanf.exe
=============================================================
1 of 3 tests failed
See tests/misc/test-suite.log
And in the test-suite.log is the following:
gmp_vsprintf wrong
fmt |%Mu|
got |4294967295|
want |8589934591|
got_len 10
want_len 10
I wonder why the test works in your environment? Maybe the mingw64
cross-compiler can print the posix modifiers by default? Or you may have a
different build, with different options compiled in, than I have? I'm using the
personal build by sezero, the one that was released on 2010-10-03. If you let
me know which build you are using, I can go ask on the mingw64 mailing list.
Are you by any chance compiling in a cygwin environment? I think printf would
work differently there and actually recognize the %llu modifier.
-David C.
Sisyphus
----- Original Message -----
From: "David Cleaver"
> However, I still get the problem with the t-printf test failing saying:
> PASS: t-locale.exe
> FAIL: t-printf.exe
> PASS: t-scanf.exe
> =============================================================
> 1 of 3 tests failed
> See tests/misc/test-suite.log
>
> And in the test-suite.log is the following:
>
> gmp_vsprintf wrong
> fmt |%Mu|
> got |4294967295|
> want |8589934591|
> got_len 10
> want_len 10
>
> I wonder why the test works in your environment? Maybe the mingw64
> cross-compiler can print the posix modifiers by default? Or you may have
> a different build, with different options compiled in, than I have? I'm
> using the personal build by sezero, the one that was released on
> 2010-10-03. If you let me know which build you are using, I can go ask on
> the mingw64 mailing list. Are you by any chance compiling in a cygwin
> environment? I think printf would work differently there and actually
> recognize the %llu modifier.
Yeah - I don't see any configure checks for supported modifiers when I hunt
through the configure output. (It must be mpfr that I'm thinking of.)
I'm using one of the "Automated Builds" provided by the mingw64.sf team.
It's version 4.7.0. (MinGW, no Cygwin btw.)
I don't know that it actually supports the %llu modifier.
I have this little test program:
#include <stdio.h>
#include <inttypes.h>
int main(void) {
uintmax_t x = 1125899906842749LL;
printf("%llu\n", x);
return 0;
}
It builds silently when I omit the -Wall switch, but when I build it with:
x86_64-w64-mingw32-gcc -o try.exe try.c -Wall
I get this:
C:\_64\c>x86_64-w64-mingw32-gcc -o try.exe try.c -Wall
try.c: In function 'main':
try.c:7:2: warning: unknown conversion type character 'l' in format
[-Wformat]
try.c:7:2: warning: too many arguments for format [-Wformat-extra-args]
Then, when I execute try.exe it prints out the number correctly:
C:\_64\c>try
1125899906842749
Do you get different behaviour with your compiler ?
Cheers,
Rob
David Cleaver
On 12/15/2011 11:11 PM, Sisyphus wrote:
> C:\_64\c>x86_64-w64-mingw32-gcc -o try.exe try.c -Wall
> try.c: In function 'main':
> try.c:7:2: warning: unknown conversion type character 'l' in format [-Wformat]
> try.c:7:2: warning: too many arguments for format [-Wformat-extra-args]
>
> Then, when I execute try.exe it prints out the number correctly:
>
> C:\_64\c>try
> 1125899906842749
>
> Do you get different behaviour with your compiler ?
>
> Cheers,
> Rob
I get similar 'and' different behavior with my compiler. The similarity is
that, without -Wall it silently/successfully builds the program. With -Wall, it
gives the following error:
$ gcc -o try.exe try.c -Wall
try.c: In function 'main':
try.c:6: warning: unknown conversion type character 'l' in format
try.c:6: warning: too many arguments for format
Then, when I run try.exe, I get the following output:
$ try.exe
125
Can you post your output when you run:
x86_64-w64-mingw32-gcc -v
I'd like to bring this up on the mingw64 mailing list to see if they can help us
track down why we are seeing different behavior. If you're interested, here is
my 'gcc -v':
Using built-in specs.
Target: x86_64-w64-mingw32
Configured with: ../gcc44-svn/configure --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-multilib --enable-checking=release
--prefix=/mingw64 --with-sysroot=/mingw64
--enable-languages=c,c++,fortran,objc,obj-c++ --enable-libgomp
--with-gmp=/mingw64 --with-mpfr=/mingw64 --disable-nls --disable-win32-registry
Thread model: win32
gcc version 4.4.5 20101001 (release) [svn/rev.164871 - mingw-w64/oz] (GCC)
Thanks for working with me on this. I'll talk with you later.
-David C.
Sisyphus
----- Original Message -----
From: "David Cleaver"
> I get similar 'and' different behavior with my compiler. The similarity
> is that, without -Wall it silently/successfully builds the program.
> With -Wall, it gives the following error:
> $ gcc -o try.exe try.c -Wall
> try.c: In function 'main':
> try.c:6: warning: unknown conversion type character 'l' in format
> try.c:6: warning: too many arguments for format
>
> Then, when I run try.exe, I get the following output:
> $ try.exe
> 125
Hmm ...125 is the value contained in the 32 least significant bits.
> Can you post your output when you run:
> x86_64-w64-mingw32-gcc -v
Sure:
C:\_64>x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=c:/_64/alt/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with:
../../../build/gcc/src/configure --target=x86_64-w64-mingw32 --
prefix=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root --with-sysroot=/c
/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root --enable-languages=all,obj
-c++ --enable-fully-dynamic-string --disable-multilib
Thread model: win32
gcc version 4.7.0 20110410 (experimental) (GCC)
> I'd like to bring this up on the mingw64 mailing list to see if they can
> help us track down why we are seeing different behavior. If you're
> interested, here is my 'gcc -v':
>
> Using built-in specs.
> Target: x86_64-w64-mingw32
> Configured with:
> ../gcc44-svn/configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
> --disable-multilib --enable-checking=release --prefix=/mingw64 --with-sysroot=/mingw64
> --enable-languages=c,c++,fortran,objc,obj-c++ --enable-libgomp --with-gmp=/mingw64
> --with-mpfr=/mingw64 --disable-nls --disable-win32-registry
> Thread model: win32
> gcc version 4.4.5 20101001 (release) [svn/rev.164871 - mingw-w64/oz] (GCC)
>
> Thanks for working with me on this. I'll talk with you later.
You're welcome.
I'm subscribed to the (mingw-w6...@lists.sourceforge.net) mingw64
mailing list. If you raise it there I'll be able to follow the thread - and
that's something I'll do with some interest.
Cheers,
Rob
Jason
I've tested and done a few minor tweeks and the current svn now passes tests on all the gcc farm , mingw64, cygwin and mingw32
, I'll try and do a few MSVC tests tonight , and then we can release rc2
Jason
Jason
Hi
Well christmas got in the way , so I'll release it later today
Jason