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.
> 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
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.
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.
----- 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'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 ?
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.
> 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
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.
----- 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
> 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 ?
> 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':
----- 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
> 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':
> Thanks for working with me on this. I'll talk with you later.
You're welcome. I'm subscribed to the (mingw-w64-pub...@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.
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
On Thursday 22 December 2011 09:35:50 Jason wrote:
> Hi
> 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
Hi
Well christmas got in the way , so I'll release it later today
