Re: [mpir-devel] MPIR-2.6.0-alpha3 released
- Original Message - From: Bill Hart goodwillh...@googlemail.com To: mpir-devel mpir-devel@googlegroups.com Sent: Friday, October 19, 2012 7:48 AM Subject: [mpir-devel] MPIR-2.6.0-alpha3 released Hi all, We have just released alpha3 of MPIR-2.6.0. This fixes the reported build issues on ia64 and a few other minor issues noted since the last alpha. Further build and test reports are highly desired. Builds and tests fine for me - mingw64 (gcc-4.7.0). It would also be a great help if make tune could be run in the tune directory and the output, along with the output of config.guess, could be posted to the list. For config.guess I get: $ config.guess k8-pc-mingw32 The output of 'make tune' is attached (tune.txt). Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR-2.6.0-alpha3 released
- Original Message - From: Sisyphus The output of 'make tune' is attached (tune.txt). At least it *will* be attached if I can just hit the right icons in the right order . Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. make tuneup.exe make[1]: Entering directory `/c/comp/mpir-2.6.0/tune' x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c tuneup.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c sqr_basecase.c for i in divrem_2.c gcd.c gcdext.c get_str.c mul_n.c mullow_n.c mulhigh_n.c mul.c tdiv_qr.c toom4_mul_n.c toom4_mul.c toom3_mul.c toom3_mul_n.c toom8h_mul.c toom8_sqr_n.c mulmod_2expm1.c rootrem.c divrem_euclidean_r_1.c divrem_hensel_qr_1.c rsh_divrem_hensel_qr_1.c dc_divappr_q.c dc_div_qr.c dc_div_qr_n.c inv_divappr_q.c inv_div_qr.c tdiv_q.c dc_bdiv_qr.c dc_bdiv_qr_n.c dc_bdiv_q.c ; do \ echo #define TUNE_PROGRAM_BUILD 1 $i; \ echo #include \mpn/generic/$i\ $i; \ done x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c divrem_2.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c gcd.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c gcdext.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c get_str.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c mul_n.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c mullow_n.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c mulhigh_n.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c mul.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c tdiv_qr.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c toom4_mul_n.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c toom4_mul.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c toom3_mul.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c toom3_mul_n.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c toom8h_mul.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c toom8_sqr_n.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c mulmod_2expm1.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c rootrem.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c divrem_euclidean_r_1.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c divrem_hensel_qr_1.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c rsh_divrem_hensel_qr_1.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c dc_divappr_q.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c dc_div_qr.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c dc_div_qr_n.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c inv_divappr_q.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c inv_div_qr.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c tdiv_q.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c dc_bdiv_qr.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c dc_bdiv_qr_n.c x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../tests -m64 -O3 -march=k8 -mtune=k8 -c dc_bdiv_q.c for i in split_bits.c
Re: [mpir-devel] Re: MPIR 2.6 release progress
- Original Message - From: Pavel Holoborodko My environment: 1. Windows 7 Ultimate x64. 2. Latest MinGW32 with gcc 4.7.0 (installed from official site: http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/mingw-get-inst-20120426/mingw-get-inst-20120426.exe/download ) Hi Pavel, (This is an offlist post.) I was keen to grab a more recent version of autoreconf, so I downloaded the installer from the same link as you did (above). But when I executed that installer, it installed gcc-4.6.2 (not 4.7.0) ... and no MSYS !! Do you know why that happened ? Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MPIR 2.6 release progress
- Original Message - From: Sisyphus Hi Pavel, (This is an offlist post.) Ummm ... perhaps not, though that was my intention ... ;- Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MPIR 2.6 release progress
- Original Message - From: Pavel Holoborodko pa...@holoborodko.com To: mpir-devel@googlegroups.com Sent: Thursday, September 27, 2012 10:21 PM Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress I've selected Download latest repository catalogues during the installation instead of default Use pre-packaged repository catalogues. Yep -I had used the default. Plus I've also included MSYS, C++ and Fortran compilers in Select Components window. And I hadn't scrolled down far enough to see the 'MSYS' options. Thanks, Pavel - I've rectified the mistakes I made, and all is now fine. Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MPIR 2.6 release progress
- Original Message - From: Pavel Holoborodko pa...@holoborodko.com To: mpir-devel@googlegroups.com Sent: Wednesday, September 26, 2012 5:00 PM Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress Please ignore error report from my previous e-mail. I just forgot to run autoreconf -i. I've successfully compiled (all tests passed) the latest revision 3947 from the trunk using the following configuration ./configure --prefix=/mingw --host=i686-pc-mingw32 --enable-gmpcompat I've used latest mingw32 with gcc 4.7.0 Did the generated config.h contain the following #define: #define HAVE_NATIVE_mpn_addmul_2 1 Were *any* of the HAVE_NATIVE* symbols defined in your config.h ? It may be that there's something to be learned from comparing the configure script that Pavel built with the one that shipped with rev 3947. When I build the same trunk revision (3947) with mingw64.sf's (64-bit) gcc-4.7.0 compiler, I find that *none* of the HAVE_NATIVE* symbols are defined I also find that there's *no* problem with that for me - at least, not that I'm aware of. Am I not looking at something correctly ? Is it that the failure to define the HAVE_NATIVE symbols is a problem only with the mingw32 builds ? I'll build the same trunk revision with mingw.org's (32-bit) gcc-4.5.2 tomorrow night and see how that fares. (I've no time right now.) Btw, unlike Pavel, I used the configure script that came with the 'svn co' of trunk. And, while Pavel's msys shell was installed by mingw-get-inst-20120426.exe, mine was installed by mingw-get-inst-20110802.exe. (I use the same msys shell for both 32-bit and 64-bit builds.) Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] _Decimal64 support for mpfr
- Original Message - From: Brian Gladman b...@gladman.plus.com To: mpir-devel@googlegroups.com Sent: Tuesday, August 07, 2012 5:36 PM Subject: Re: [mpir-devel] _Decimal64 support for mpfr -Original Message- From: Sisyphus Sent: Tuesday, August 07, 2012 3:27 AM To: mpir Subject: [mpir-devel] _Decimal64 support for mpfr Hi, I can build mpfr-3.1.1 with the mpfr_set_decimal64() and mpfr_get_decimal64() functions if I base the mpfr build on gmp-5.0.5. But if I try to base the mpfr build on mpir-2.5.1, configure fails: checking how to run the C preprocessor... x86_64-w64-mingw32-gcc -E checking if compiler knows _Decimal64... yes checking if _GMP_IEEE_FLOATS is defined... no configure: error: decimal float support requires _GMP_IEEE_FLOATS I take it that the gmp component of mpir-2.5.1 needs updating in order to have access to the two _Decimal64 functions. Will this _Decimal64 support be available in the next release of mpir ? === Hi Rob, It is not on our 'to do' list for the next release but my guess is that it would not be hard to add this __IF__ someone volunteers to do it. Brian Thanks Brian. It's not such a big issue for me I just wanted to know if it was on the immediate agenda. If I need to, I can always access this functionality by using the mpfr that was built against gmp (instead of the mpfr that was built against mpir). There's a performance hit in taking that route for 64-bit builds, as my 64-bit (Mingw) builds of gmp are generic C - but for the tasks at hand, this performance hit is of no significance. I still intend to keep a foot in both camps anyway :-) Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MPIR 2.6 release progress
- Original Message - From: Bill Hart I don't know what this _Decimal64 thing is about. mpir-3.1.1 builds just fine on my machine. Perhaps the person who reported this forgot to specify where mpir was with --with-gmp-include=... and --with-gmp-lib=... or perhaps forgot to pass --enable-gmpcompat to MPIR's configure. Assuming that no-one else has posted about this, I guess *I* must be the person ;-) I think I got the configure args right. I used --with-gmp-build= instead of the include and lib variants. I also (think I) remembered to --enable-gmpcompat when building mpir-2.5.1 and to specify --enable-decimal-float when building mpfr. To build the two set/get _Decimal64 functions into mpfr-3.1.1, it seems to be necessary that _GMP_IEEE_FLOATS be defined. (I think it's the --enable-decimal-float that pulls in the condition that _GMP_IEEE_FLOATS be defined.) AFAICT, this is handled by gmp-impl.h in gmp-5.0.5, but when I grep the entire mpir-2.5.1 source I can find only one file that contains the string _GMP_IEEE_FLOATS, and that's the ChangeLog. Do you mean that you have successfully built mpfr-3.1.1 against mpir-2.5.1 such that mpfr_set_decimal64() and mpfr_get_decimal64() were built in ? If so, I'll have another crack at it. Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
[mpir-devel] _Decimal64 support for mpfr
Hi, I can build mpfr-3.1.1 with the mpfr_set_decimal64() and mpfr_get_decimal64() functions if I base the mpfr build on gmp-5.0.5. But if I try to base the mpfr build on mpir-2.5.1, configure fails: checking how to run the C preprocessor... x86_64-w64-mingw32-gcc -E checking if compiler knows _Decimal64... yes checking if _GMP_IEEE_FLOATS is defined... no configure: error: decimal float support requires _GMP_IEEE_FLOATS I take it that the gmp component of mpir-2.5.1 needs updating in order to have access to the two _Decimal64 functions. Will this _Decimal64 support be available in the next release of mpir ? Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MPIR support for 64-bit integers on Windows
- Original Message - From: Cactus You will also ned to overwrite mpir.h with the version attached here (I overlooked this when making the ZIP file). But isn't mpir.h built by the configure process ? It's not in the top-level directory of the svn source that I downloaded, but *does* appear there after./configure has been run. If that's so, then we would need to introduce that mpir.h into the build *after* we've run ./configure - which is a dubious practice. (Introducing it prior to ./configure would be equally dubious - and I'm guessing it would only get overwritten anyway.) Not sure if that has anything to do with the problem that David is experiencing, and I won't have time to take a look for a day or two. (Sorry if I've missed something, and am being stupid.) Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR-2.5.0-rc1 released
- 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:\_64x86_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-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. Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR-2.5.0-rc1 released
- 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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR-2.5.0-rc1 released
- 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\cx86_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\ctry
1125899906842749
Do you get different behaviour with your compiler ?
Cheers,
Rob
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MPIR support for 64-bit integers on Windows
- Original Message - From: Cactus Since this version involves a lot of changes, we need an extended testing period so we need volunteers who are willing to build it, test it and use it in some applications. I can do that. Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] MPIR-2.5.0-rc1 released
- 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 -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Fwd: Huge number crash ...
- Original Message - From: Jason ja...@njkfrudils.plus.com To: mpir-devel@googlegroups.com Sent: Sunday, September 25, 2011 4:36 AM Subject: [mpir-devel] Fwd: Huge number crash ... -- Forwarded Message -- Subject: Huge number crash ... Date: Wednesday 21 September 2011, 18:38:42 From: manu hobert manu.hob...@gmail.com To: thempirt...@gmail.com Hello, I'm trying to make some programs to calculate some quite huge numbers, like phi with 1 000 000 000 decimals (witch uses about 1GB ram) ... but when my ram usage got too high ~1GB it crashed and said: cannot allocate memory (size=*). this happens with all of my programs, as soon as it goes too big it crashes. i have enough ram though, i've got 4GB ram (when i run my progs i have about 2.5 - 3 GB free memory). I haven't got any idea why this happens to me ... Try rebuilding mpir with the configure option --enable-alloca=malloc-reentrant. If reentrancy is not required, configuring instead with --enable-alloca=malloc-notreentrant should be faster (and therefore preferable). See http://gmplib.org/manual/Build-Options.html#Build-Options . I'm not sure if that will solve your problem - but worth trying, imo. Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MPIR-2.4.0-rc2 released
- Original Message - From: jason ja...@njkfrudils.plus.com To: mpir-devel mpir-devel@googlegroups.com Sent: Thursday, June 09, 2011 7:42 PM Subject: [mpir-devel] Re: MPIR-2.4.0-rc2 released another pass on MinGW64 nehalem-w64-mingw32 gcc version 4.5.3 20110207 (prerelease) (GCC) NEHALEM FWIW, no problems here with x86_64-w64-mingw32-gcc: gcc version 4.7.0 20110410 (experimental) (GCC) I'm wondering about the problem that Case found, and Cactus fixed. I take it that this was a problem not detected by the test suite (as RC1 also passed all of its tests for me). That being so, have any tests been added to the test suite to verify that this problem is indeed fixed ? Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Gamma Function
- Original Message - From: Bob Smith bsm...@sudleyplace.com To: mpir-devel@googlegroups.com Sent: Friday, May 13, 2011 4:00 AM Subject: [mpir-devel] Gamma Function I need this function to extend mpz_fac_ui to non-integral arguments. I see it's in the MPFR library. If I calculate in that library, is there a direct way to convert the result to mpf format? Or should I solve this problem entirely differently? My code needs to run on both Windows and Linux platforms. The mpfr_get_f() function is your friend. Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [Mingw-w64-public] [mpir-devel] Re: MinGW64 -undefinedreference to gmpn symbols.
- Original Message - From: Sisyphus Apart from 'gcc -v' or 'gcc --version' there's apparently nothing - and I have at least one mingw64 64-bit compiler that doesn't report the date even then. But on the mingw64 mailing list (where I asked about this, in the thread Compiler incompatibilities) Ozkan presented this possible alternative: ###quote### In that case, if mpir is using autotools a configury check can be done. I have the following in one of my projects which can be adapted to their needs I guess: dnl === Check for underscore on external symbols = AC_MSG_CHECKING(whether external symbols need an underscore prefix) AC_TRY_LINK( [asm(.long _bar); int bar;], [], AC_DEFINE(HAVE_SYM_PREFIX_UNDERSCORE, 1, [Define this if C symbols are prefixed with an underscore]) AC_MSG_RESULT(yes), AC_MSG_RESULT(no) ) ###end quote### Thanks again, Ozkan. Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MinGW64 - undefined reference to gmpn symbols.
- Original Message - From: jason What's the date on those compilers ? If they're more recent than my 20100414 and 20100306 I'll see if I can grab one or more of them to see if they work for me. yep yours were about a year old they were mingw-w64-1.0-bin_i686-mingw-20110207 and 20110408 Thanks for that, jason. These are both version 4.5.3. I haven't tried to build mpir with them. I'm sure it works, however, as both of these compilers (just like the 4.7.0 that I grabbed) are incapable of using anything my aging 4.6.0 built. Just posted to the mingw64 mailing list and found out the following: --quote-- Win64-targeting builds from mingw-w64 up to 2010-04-27 didn't follow MSVC x64 convention and did *not* prepend an undersocore to the symbols: this is why you are seeing the incompatibilities with the newer toolchains. All win64-targeting toolchains created after 2010-04-28, including the sezero's gcc-4.4-based personal builds follow the MS convention. You should not be using those old toolchains. --end quote-- That's the secret then - just use a compiler later than 20100428. (If only I'd waited another fortnight before I downloaded that compiler :-) I guess mpir expects that the above mentioned convention is being followed - whereas the other libraries that I've been successfully building over the last year or so, make no such assumption and (presumably) allow the symbols to be prefixed correctly for the particular compiler. Looks like I've got some work to do when I can get around to it gunna have to ditch that lovely ol' 4.6.0 compiler sooner or later anyway. Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MinGW64 - undefined reference to gmpn symbols.
- Original Message - From: Jason That's the secret then - just use a compiler later than 20100428. (If only I'd waited another fortnight before I downloaded that compiler :-) Ah Ah , I'll put a note on our website about this Ozkan posted a follow-up, explaining that he hadn't quoted the details of the non-compliance correctly: --quote-- It seems I have typo in my explanations: our old x64-compilers *did* prepend an underscore to the symbols (bad behavior), but the new compilers do not which is the expected MS-compatible behavior. --endquote-- make check fails for a C++ shared lib build , due to the lib's being in the wrong place , almost certainly an autotools problem (MinGW32 had the same problem until we upgraded autotools) make speed , try , or tune , all won't build due to autotools not setting the correct include paths I wonder if the last two problems with autotools are to do with them assuming *-pc-mingw32 rather than *-w64-mingw32 Sounds feasible to me. I know my 64-bit cross-compiler has the includes in mingw/include and the libraries in mingw/lib, whereas the 32-bit compiler (from mingw.org) has them in include and lib repectively. There's a trap, however - sezero's 64-bit builds (and perhaps also some of the other private builds) put them in include and lib (not mingw/include and mingw/lib). That being the case, using one of sezero's 64-bit compilers might currently work ... if your hypothesis is correct :-) Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MinGW64 - undefined reference to gmpn symbols.
- Original Message - From: Jason Looks like a compiler bug. weren't you using a gcc-4.6 prerelease? Yes, I was using (as I normally do): gcc version 4.6.0 20100414 (experimental) (GCC) I also have built mpir-2.3.1 using: gcc version 4.4.4 20100306 (prerelease) [svn/rev.157253 - mingw-w64/oz] (GCC) With that 4.4.4 compiler there's no problem with a generic build, but I still get the same errors when assembler is involved. And I've just now installed: gcc version 4.7.0 20110410 (experimental) (GCC) It builds mpir-2.3.1 just fine and with assembler, too. Yay !! just try another install in another directory , and make sure your path includes nothing from the old install I've just given that a go and it doesn't help with the assembler build - I still get the same errors. (Didn't bother checking the generic build.) My path never includes the location of any compilers, so that won't have been an issue. (My compiler always gets found according to what's specified in etc/fstab.) Looks like both my 4.6.0 and 4.4.4 contain a bug that has since been fixed. Might have to give 4.6.0 the flick, which is a pity. It has done a power of work, and very reliably (until it had to confront yasm). Is there any point in digging deeper ? The problem has a clearly identifying signature - and the fix is (apparently) to install a newer build of the compiler. AC_MSG_WARN([+--]) AC_MSG_WARN([| Cannot determine global symbol prefix.]) AC_MSG_WARN([| $NM output doesn't contain a global data symbol.]) AC_MSG_WARN([| Will proceed with no underscore.]) AC_MSG_WARN([| If this is wrong then you'll get link errors referring]) AC_MSG_WARN([| to ___gmpn_add_n (note three underscores).]) AC_MSG_WARN([| In this case do a fresh build with an override,]) AC_MSG_WARN([| ./configure gmp_cv_asm_underscore=yes]) and try no I gave that a go before trying the 4.7.0 compiler but , other than the config.log reporting no instead of yes, it made no difference afaict. I still got the same 'undefined reference' errors, and the global symbol prefix was unchanged. (I liked the hackish idea, but.) Thanks for taking the time to persevere with me. Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MinGW64 - undefined reference to gmpn symbols.
- Original Message - From: Jason Looks like both my 4.6.0 and 4.4.4 contain a bug that has since been fixed. But they worked for me and Brian , so maybe not... What's the date on those compilers ? If they're more recent than my 20100414 and 20100306 I'll see if I can grab one or more of them to see if they work for me. I still may have issues, as there appears to be some incompatibility between 4.7.0 and 4.6.0. For example, *both* the mpir library that Jason built, and the mpir library that I built with 4.7.0 work fine with my 4.7.0 compiler, but *neither* of them work with my 4.6.0 compiler. (Same old 'undefined reference' problems.) And 4.7.0 won't work nicely with the perl that 4.6.0 built - and that won't do. (About to have a closer look at this.) Amazingly, my 4.7.0 works nicely with the perl built by Microsoft Platform SDK for Windows Server 2003 R2, as also does my 4.6.0. Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MinGW64 - undefined reference to gmpn symbols.
- Original Message - From: Sisyphus And 4.7.0 won't work nicely with the perl that 4.6.0 built - and that won't do. (About to have a closer look at this.) Btw, the statement 4.7.0 won't work nicely with the perl that 4.6.0 built translates to something like I can't use 4.7.0 to build perl extensions (ie perl modules that need some C compilation) with my 4.6.0-built perl. Turns out it's just that the perl import library built by 4.6.0 has the wrong global symbols prefix for 4.7.0 - so no perl symbols get found. (The thing of note here is that msys, yasm and mpir are not involved - yet there's still that global symbols prefix issue.) Two possible fixes: 1) Hack perl so that linking is done directly to the perl dll (instead of the perl import library); 2) Use gendef.exe and 4.7.0's dlltool to build an appropriate import library. (Both approaches work, btw.) Amazingly, my 4.7.0 works nicely with the perl built by Microsoft Platform SDK for Windows Server 2003 R2, as also does my 4.6.0. Well ... not so amazing, when I think about it. Those SDK-built perls have already been hacked so that mingw64 links directly to the perl dll. In any case, for various reasons (pertaining mainly to practicality), I'd like to keep using 4.6.0. Looks like there'll need to be an awful lot of rebuilding if I switch to 4.7.0. I finally got to thinking (which is a dangerous thing for me to be doing) ... I could build a dynamic (assembler) build of mpir using 4.7.0, then use gendef and 4.6.0's dlltool to create a 4.6.0-compliant import lib from the 4.7.0-built dll. That way, I end up with a dynamic assembler build of mpir that I can use with 4.6.0. And, sure enough, that works !! It then occurred to me that the dll I built didn't have to be built using 4.7.0 - I could have used 4.6.0 to build it. So many hacks and not one of them right (hacker's heaven ;-) Only drawback (from my pov) is that I've ended up with a dynamic library - better if I could get a static lib that I could use with 4.6.0. Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: gmp.h - minor issues
- Original Message - From: jason On Apr 12, 3:09 am, Sisyphus Also, I find in gmp.h: #define __GNU_MP_VERSION 5 #define __GNU_MP_VERSION_MINOR 0 #define __GNU_MP_VERSION_PATCHLEVEL 1 #define GMP_VERSION 5.0.1 Not sure that we really want that when mpz_powm_sec (available only with gmp-5) is missing from the mpir implementation. Yep , we made a decision not to do an mpz_powm_sec as we didn't think that a general bignum library was the right place for a secure powm, although barring that , we should put some note on the website Hmmm ... my feeling is that the significance of mpz_powm() would also be drastically reduced if not for its importance in matters related to security ... so there's probably an argument for not supporting it, too. (But I'll leave that to those far more skilled in sophistry than I :-) I think that if forking gmp is the aim, then the user probably expects that it has been forked warts and all ... and therein could be some sort of argument that making those sorts of selective decisions is outside of your jurisdiction. Please take that point of view with a grain of salt. Obviously, if gmp were to start doing really ridiculous things, I don't think that any user would expect mpir to follow suit ... but then, I don't think gmp is about to embark upon a path of doing really ridiculous things. And although gmp is a general bignum library, bear in mind that it's also often used for doing things associated with security. If I'm not mistaken, openssl now (optionally) uses it. So it's not unreasonable, imo, that it should lend itself to operations that target security. And yes, some documentation about this wouldn't be out of order. (Of course, I would've missed that documentation, anyway :-))) Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: gmp.h - minor issues
- Original Message - From: Cactus I don't see how this could be outside the jurisdiction of those who forked the MPIR version of GMP. Yes - as regards MPIR, you are free to implement whatever bits and pieces you choose. It's just that when one builds with --enable-gmpcompat, one (naively) expects full compatibility with gmp. One doesn't expect the range of functions provided to have been censored. But one soon discovers the errors of one's expectations ... and adapts. Cheers, Rob -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
Re: [mpir-devel] Re: MinGW64 - undefined reference to gmpn symbols.
- Original Message -
From: Jason
you could also try
./configure --build=none-w64-mingw32 for a pure C build , incase it's just
the
assembler that is having problems.
(The above was from an off list exchange. Jason has also sent me his build
of mpir-2.3.1 for reference - ie the entire build directory.
Putting this discussion back on list.)
Generic C build is pretty good. The only problem is that t-aors_1.exe won't
build. All other tests build and pass.
Here's the error:
x86_64-w64-mingw32-gcc.exe -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../tests
-DNO_ASM -O3 -c t-aors_1.c
t-aors_1.c:271:1: internal compiler error: in
cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1009
Please submit a full bug report,
with preprocessed source if appropriate.
Anyway - my ,main problem is looking more and more like a yasm issue, and
that's *not* good news for me (as I don't code in assembler, and I've never
used yasm).
Jason, I keep seeing discrepancies (in our respective builds) in the number
of underscores that precede the symbol name. In your config.log, I see:
configure:26548: checking if globals are prefixed by underscore
configure:26558:
x86_64-w64-mingw32-gcc.exe -std=gnu99 -O2 -m64 -march=core2 -mtune=core2 -c
conftest.c 5
configure:26561: $? = 0
configure:26579: result: no
Whereas mine contains:
configure:26540: checking if globals are prefixed by underscore
configure:26550:
x86_64-w64-mingw32-gcc.exe -std=gnu99 -O2 -m64 -march=k8 -mtune=k8 -c
conftest.c 5
configure:26553: $? = 0
configure:26571: result: yes
Is this something that's architecture dependent ? (If so, then I would think
it possible that both configure scripts have got it right. If not, then one
script has got it wrong and it's not difficult to guess which one that
might be.)
I have an AMD64 processor. Jason, what do you have ?
I assume also it's a difference in our processors that accounts for the
different -march and -mtune settings ? (For me, they're 'k8', whereas Jason
has 'core2'.)
Is it known if *anyone* has successfully built a 64-bit mpir (with
assembler) on an AMD64 box with the MinGW64 compiler ?
Should the library that Jason built and sent over to me be usable on my
machine ? It's not working for me :
##
C:\_64\ctype mpir.c
#include stdio.h
#include mpir.h
int main(void) {
mpz_t y;
mpz_init_set_str(y, 1101101101101, 2);
mpz_out_str(0, 16, y);
mpz_clear(y);
return 0;
}
C:\_64\cx86_64-w64-mingw32-gcc -o mpir.exe
mpir.c -IC:/temp/temp -LC:/temp/temp/.libs -lmpir
C:\Users\Rob\AppData\Local\Temp\ccguXd86.o:mpir.c:(.text+0x22): undefined
reference to `__gmpz_init_set_str'
C:\Users\Rob\AppData\Local\Temp\ccguXd86.o:mpir.c:(.text+0x38): undefined
reference to `__gmpz_out_str'
C:\Users\Rob\AppData\Local\Temp\ccguXd86.o:mpir.c:(.text+0x44): undefined
reference to `__gmpz_clear'
collect2: ld returned 1 exit status
C:\_64\c
##
(That's probably enough questions for this post :-)
Cheers,
Rob
--
You received this message because you are subscribed to the Google Groups
mpir-devel group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
[mpir-devel] gmp.h - minor issues
Hi, More about my problems with the MinGW64 compiler later. In the meantime, I notice that my gmp.h fails to add the -std=gnu99 switch to __GMP_CC. It adds it for __MPIR_CC, but not __GMP_CC. This happens with both my MinGW64 compiler, and mingw.org's 32 bit (gcc-3.4.5) compiler. Also, I find in gmp.h: #define __GNU_MP_VERSION 5 #define __GNU_MP_VERSION_MINOR 0 #define __GNU_MP_VERSION_PATCHLEVEL 1 #define GMP_VERSION 5.0.1 Not sure that we really want that when mpz_powm_sec (available only with gmp-5) is missing from the mpir implementation. I have some code that relies on the value of __GNU_MP_VERSION to determine whether mpz_powm_sec is available or not. Using the mpir replacement, that obviously doesn't work. (Easily fixed in my code, of course, by checking also whether __MPIR_VERSION is defined.) Cheers, Rob (with all fingers crossed ... ) -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-devel@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
