http://blog.gmane.org/gmane.comp.lib.gmp.bugs hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4062 <pre> Please don't mix everything. If you want to provide several unrelated patches, do so in different emails with explanations for each. Agreed. The currently suggested change is not possible for us to act on. What you need to do it to describe problem, optionally suggest a fix, explain any fix. Repeat for each problem. Don't forget to describe environment where each problem occurs (compiler version, configure options, etc). Please refrain from formatting changes in any patches. Please just insert patches in the mails, as plain text. No tar file, no compression. </pre> Torbjorn Granlund 2013-05-16T22:09:05 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4061 <pre> mode32 is only valid on PowerPCs (as opposed to Intel Macs), only necessary if you're running 32-bit MacOS X on a 64-bit PPC CPU, and MacOS X on PPC implies &lt;= 10.5[.8] (Darwin 9 or earlier). Well, mode32 is never "necessary", it is a GMP mode (or as we slightly incorrectly call it, ABI) for 64-bit PPC processors in 32-bit mode, using 64-bit 'limbs'. One may also use a plain 32-bit build with 32-bit limbs. Not much attention has been given to mode32 optimisation, since we expect mode64 to be used by almost everybody with these CPUs. Torbjörn _______________________________________________ gmp-bugs mailing list gmp-bugs&lt; at &gt;gmplib.org http://gmplib.org/mailman/listinfo/gmp-bugs </pre> Torbjorn Granlund 2013-05-16T21:58:29 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4060 <pre> mode32 is only valid on PowerPCs (as opposed to Intel Macs), only necessary if you're running 32-bit MacOS X on a 64-bit PPC CPU, and MacOS X on PPC implies &lt;= 10.5[.8] (Darwin 9 or earlier). So that should probably read powerpc*-apple-darwin{8,9}* or similar, as an /additional/ entry. (/GMP's/ config.guess doesn't return powerpc64-* but a more specific CPU type for a couple of 64-bit PowerPC CPUs, in contrast to FSF's config.guess, as far as I know.) He could install Linux on it... -leif </pre> Leif Leonhardy 2013-05-16T21:31:10 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4059 <pre> What compiler were you using? Apple used to provide a compiler called gcc that advertised itself as version 4.0 but was really some weird chimera. On those systems, the compiler called gcc-4.2 usually worked better. Please don't mix everything. If you want to provide several unrelated patches, do so in different emails with explanations for each. You are probably one of the last dinosaurs with a ppc mac ;-) </pre> Marc Glisse 2013-05-16T20:07:33 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4058 <pre> One reason to use --disable-assembly is if the assembler invocations don't work for some reason. So I think we really should avoid using assembly source files. Resorting to gcc inline assembly (when using gcc) might be a less bad alternative for the common case of gcc. I commited a fix. The problem code is there just to test some GMP function's resillience to rounding mode changes. And it only works for the obsolete x87 insns working off the floating-point stack. </pre> Torbjorn Granlund 2013-05-16T19:43:57 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4057 <pre>Hi gmp-bugs, Could you take a look at the patch file I have attached to this note. I have been having trouble with shared lib support on Apple OS X 10.5.8 (ppc), Specifically duplicate symbols then later on (when building nettle 2.6) I encountered Undefined symbols (not of required architecture). The patch fixes the duplicate symbols and also adds a pkg-config file into the mix (you will need to run autoreconf to get it into the Makefile). cd gmp-5.1.1 patch -p1 &lt; ../osx.patch autoreconf Could you also alter your manual web page: http://gmplib.org/manual/Known-Build-Problems.html#Known-Build-Problems from ... "MacOS X (‘*-*-darwin*’)     Libtool currently only knows how to create shared libraries on MacOS X using the     native cc (which is a modified GCC), not a plain GCC. A static-only build should work though (‘--disable-shared’)." to ... "MacOS X (‘*-*-darwin*’)     If you are using a 32 bit version of MacOS X (10.5.8 or lower) then you should ensure that you configure with:     ./configure ABI=mode32 " this will get around the "Undefined symbols (not of required architecture)" problem. OS X 10.6 builds as 64 bit by default so should not need the ABI variable set. I have successfully run "make check" and successfully built nettle 2.6 with gmp support included. many thanks Simon Lazenby_______________________________________________ gmp-bugs mailing list gmp-bugs&lt; at &gt;gmplib.org http://gmplib.org/mailman/listinfo/gmp-bugs </pre> Simon Lazenby 2013-05-16T19:29:30 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4056 <pre> To me, it seems good enough if we can set the rounding mode on the most common/important platforms. And the current code looks x86-only, so using fenv.h instead should widen the set of systems where this works. Regards, /Niels </pre> Niels Möller 2013-05-16T15:33:21 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4055 <pre> In fenv.h, fe[sg]etround. But that's C99, so windows has _controlfp_s instead... We don't have to test the rounding mode on platforms where we don't know how to use it. </pre> Marc Glisse 2013-05-16T15:23:04 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4054 <pre> And there are no "standard" interfaces for that? (I'm ignorant of deeper floating point details). One reason to use --disable-assembly is if the assembler invocations don't work for some reason. So I think we really should avoid using assembly source files. Resorting to gcc inline assembly (when using gcc) might be a less bad alternative for the common case of gcc. Regards, /Niels </pre> Niels Möller 2013-05-16T15:15:55 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4053 <pre> That seems like a genuine bug. I can reproduce it with ~/hack/gmp/configure ABI=32 --disable-assembly on a GNU/linux x86_64 system as well. Make check gets link errors, libtool: link: gcc -std=gnu99 -m32 -O2 -pedantic -fomit-frame-pointer -mtune=corei7 -march=corei7 -DNO_ASM -o .libs/t-bswap t-bswap.o ./.libs/libtests.a /home/nisse/build/gmp-32-noasm/.libs/libgmp.so ../.libs/libgmp.so ./.libs/libtests.a(misc.o): In function `tests_hardware_setround': misc.c:(.text+0xcc6): undefined reference to `x86_fstcw' misc.c:(.text+0xcd6): undefined reference to `x86_fldcw' ./.libs/libtests.a(misc.o): In function `tests_hardware_getround': misc.c:(.text+0xd30): undefined reference to `x86_fstcw' collect2: ld returned 1 exit status make[4]: *** [t-bswap] Error 1 Tricky issue. We probably really need to manipulate the rounding mode to make testing reliable, but I am not sure about that. But if we let --disable-assembly also disable the asm files in 'tests' we exclude the code for rounding mode manipulation... </pre> Torbjorn Granlund 2013-05-16T15:07:03 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4052 <pre> In general, that's to be expected. There are plenty of optional machine dependent functions. That seems like a genuine bug. I can reproduce it with ~/hack/gmp/configure ABI=32 --disable-assembly on a GNU/linux x86_64 system as well. Make check gets link errors, libtool: link: gcc -std=gnu99 -m32 -O2 -pedantic -fomit-frame-pointer -mtune=corei7 -march=corei7 -DNO_ASM -o .libs/t-bswap t-bswap.o ./.libs/libtests.a /home/nisse/build/gmp-32-noasm/.libs/libgmp.so ../.libs/libgmp.so ./.libs/libtests.a(misc.o): In function `tests_hardware_setround': misc.c:(.text+0xcc6): undefined reference to `x86_fstcw' misc.c:(.text+0xcd6): undefined reference to `x86_fldcw' ./.libs/libtests.a(misc.o): In function `tests_hardware_getround': misc.c:(.text+0xd30): undefined reference to `x86_fstcw' collect2: ld returned 1 exit status make[4]: *** [t-bswap] Error 1 Regards, /Niels </pre> Niels Möller 2013-05-15T12:01:44 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4051 <pre>Solaris 10 and 11 on x86 Oracle Studio Compiler 12.3 gmake 3.82 If I set the ABI to 32 then the tests/.libs/libtests.a file has different symbols than if it is compiled with ABI 64. The recipe I tried: setenv CC cc setenv CXX CC setenv M4 /usr/local/bin/m4 cd /var/tmp rm -rf gmp-5.1.1 xz -dc /usr/local/src/gnu/gmp-5.1.1.tar.xz | gtar -xvf - cd gmp-5.1.1 ./configure --prefix=/usr/local \ --disable-assembly gmake gmake check setenv ABI 32 libtool: compile: cc -D_STDC_C99= -DHAVE_CONFIG_H -I. -I.. -I.. -O -DNO_ASM -c trace.c -o trace.o &gt;/dev/null 2&gt;&amp;1 /bin/bash ../libtool --tag=CC --mode=link cc -D_STDC_C99= -O -DNO_ASM -o libtests.la memory.lo misc.lo refmpf.lo refmpn.lo refmpq.lo refmpz.lo spinner.lo trace.lo ../libgmp.la libtool: link: ar cq .libs/libtests.a .libs/memory.o .libs/misc.o .libs/refmpf.o .libs/refmpn.o .libs/refmpq.o .libs/refmpz.o .libs/spinner.o .libs/trace.o libtool: link: ranlib .libs/libtests.a libtool: link: ( cd ".libs" &amp;&amp; rm -f "libtests.la" &amp;&amp; ln -s "../libtests.la" "libtests.la" ) cc -D_STDC_C99= -DHAVE_CONFIG_H -I. -I.. -I.. -O -DNO_ASM -c t-bswap.c "../gmp-impl.h", line 3646: warning: attribute "mode" is unknown, ignored "../gmp-impl.h", line 3647: warning: attribute "mode" is unknown, ignored "../gmp-impl.h", line 3648: warning: attribute "mode" is unknown, ignored "../gmp-impl.h", line 3649: warning: attribute "mode" is unknown, ignored "../gmp-impl.h", line 3650: warning: attribute "mode" is unknown, ignored /bin/bash ../libtool --tag=CC --mode=link cc -D_STDC_C99= -O -DNO_ASM -o t-bswap t-bswap.o libtests.la ../libgmp.la libtool: link: cc -D_STDC_C99= -O -DNO_ASM -o .libs/t-bswap t-bswap.o ./.libs/libtests.a /var/tmp/gmp-5.1.1/.libs/libgmp.so ../.libs/libgmp.so -R/gmp/lib ld: warning: file ../.libs/libgmp.so: linked to /var/tmp/gmp-5.1.1/.libs/libgmp.so: attempted multiple inclusion of file Undefined first referenced symbol in file x86_fldcw ./.libs/libtests.a(misc.o) x86_fstcw ./.libs/libtests.a(misc.o) ld: fatal: Symbol referencing errors. No output written to .libs/t-bswap gmake[4]: *** [t-bswap] Error 2 gmake[4]: Leaving directory `/var/tmp/gmp-5.1.1/tests' gmake[3]: *** [check-am] Error 2 gmake[3]: Leaving directory `/var/tmp/gmp-5.1.1/tests' gmake[2]: *** [check-recursive] Error 1 gmake[2]: Leaving directory `/var/tmp/gmp-5.1.1/tests' gmake[1]: *** [check-recursive] Error 1 gmake[1]: Leaving directory `/var/tmp/gmp-5.1.1' gmake: *** [check] Error 2 host:/var/tmp/gmp-5.1.1/tests/.libs root# nm libtests.a | grep x86 [78] | 0| 0|FUNC |GLOB |0 |UNDEF |x86_fldcw [77] | 0| 0|FUNC |GLOB |0 |UNDEF |x86_fstcw host:/var/tmp/gmp-5.1.1 root# grep ^# config.h &gt; /var/tmp/gmp.config.h.32 setenv ABI 64 libtool: compile: cc -D_STDC_C99= -DHAVE_CONFIG_H -I. -I.. -I.. -xO3 -m64 -DNO_ASM -c trace.c -o trace.o &gt;/dev/null 2&gt;&amp;1 /bin/bash ../libtool --tag=CC --mode=link cc -D_STDC_C99= -xO3 -m64 -DNO_ASM -o libtests.la memory.lo misc.lo refmpf.lo refmpn.lo refmpq.lo refmpz.lo spinner.lo trace.lo ../libgmp.la libtool: link: ar cq .libs/libtests.a .libs/memory.o .libs/misc.o .libs/refmpf.o .libs/refmpn.o .libs/refmpq.o .libs/refmpz.o .libs/spinner.o .libs/trace.o libtool: link: ranlib .libs/libtests.a libtool: link: ( cd ".libs" &amp;&amp; rm -f "libtests.la" &amp;&amp; ln -s "../libtests.la" "libtests.la" ) cc -D_STDC_C99= -DHAVE_CONFIG_H -I. -I.. -I.. -xO3 -m64 -DNO_ASM -c t-bswap.c "../gmp-impl.h", line 3646: warning: attribute "mode" is unknown, ignored "../gmp-impl.h", line 3647: warning: attribute "mode" is unknown, ignored "../gmp-impl.h", line 3648: warning: attribute "mode" is unknown, ignored "../gmp-impl.h", line 3649: warning: attribute "mode" is unknown, ignored "../gmp-impl.h", line 3650: warning: attribute "mode" is unknown, ignored /bin/bash ../libtool --tag=CC --mode=link cc -D_STDC_C99= -xO3 -m64 -DNO_ASM -o t-bswap t-bswap.o libtests.la ../libgmp.la libtool: link: cc -D_STDC_C99= -xO3 -m64 -DNO_ASM -o .libs/t-bswap t-bswap.o ./.libs/libtests.a /var/tmp/gmp-5.1.1/.libs/libgmp.so ../.libs/libgmp.so -R/gmp/lib ld: warning: file ../.libs/libgmp.so: linked to /var/tmp/gmp-5.1.1/.libs/libgmp.so: attempted multiple inclusion of file cc -D_STDC_C99= -DHAVE_CONFIG_H -I. -I.. -I.. -xO3 -m64 -DNO_ASM -c t-constants.c "../gmp-impl.h", line 3646: warning: attribute "mode" is unknown, ignored "../gmp-impl.h", line 3647: warning: attribute "mode" is unknown, ignored "../gmp-impl.h", line 3648: warning: attribute "mode" is unknown, ignored "../gmp-impl.h", line 3649: warning: attribute "mode" is unknown, ignored "../gmp-impl.h", line 3650: warning: attribute "mode" is unknown, ignored /bin/bash ../libtool --tag=CC --mode=link cc -D_STDC_C99= -xO3 -m64 -DNO_ASM -o t-constants t-constants.o libtests.la ../libgmp.la libtool: link: cc -D_STDC_C99= -xO3 -m64 -DNO_ASM -o .libs/t-constants t-constants.o ./.libs/libtests.a /var/tmp/gmp-5.1.1/.libs/libgmp.so ../.libs/libgmp.so -R/gmp/lib ld: warning: file ../.libs/libgmp.so: linked to /var/tmp/gmp-5.1.1/.libs/libgmp.so: attempted multiple inclusion of file cc -D_STDC_C99= -DHAVE_CONFIG_H -I. -I.. -I.. -xO3 -m64 -DNO_ASM -c t-count_zeros.c host:/var/tmp/gmp-5.1.1/tests/.libs root# nm libtests.a | grep x86 host:/var/tmp/gmp-5.1.1/tests/.libs root# host:/var/tmp/gmp-5.1.1 root# grep ^# config.h &gt; /var/tmp/gmp.config.h.64 Note the different HAVE_HOST_CPU_FAMILY defines: host:/var/tmp/gmp-5.1.1 root# diff /var/tmp/gmp.config.h.32 /var/tmp/gmp.config.h.64 25c25 &lt; #define HAVE_HOST_CPU_FAMILY_x86 1 --- 85c85 &lt; #define SIZEOF_MP_LIMB_T 4 --- 87c87 &lt; #define SIZEOF_UNSIGNED_LONG 4 --- 89c89 &lt; #define SIZEOF_VOID_P 4 --- This extra code is added for ABI 32 only compiles: host:/var/tmp/gmp-5.1.1 root# cat -n tests/misc.c [...] 461 462 /* Set the hardware floating point rounding mode. Same mode values as mpfr, 463 namely 0=nearest, 1=tozero, 2=up, 3=down. Return 1 if successful, 0 if 464 not. */ 465 int 466 tests_hardware_setround (int mode) 467 { 468 #if HAVE_HOST_CPU_FAMILY_x86 469 int rc; 470 switch (mode) { 471 case 0: rc = 0; break; /* nearest */ 472 case 1: rc = 3; break; /* tozero */ 473 case 2: rc = 2; break; /* up */ 474 case 3: rc = 1; break; /* down */ 475 default: 476 return 0; 477 } 478 x86_fldcw ((x86_fstcw () &amp; ~0xC00) | (rc &lt;&lt; 10)); 479 return 1; 480 #endif 481 482 return 0; 483 } 484 485 /* Return the hardware floating point rounding mode, or -1 if unknown. */ 486 int 487 tests_hardware_getround (void) 488 { 489 #if HAVE_HOST_CPU_FAMILY_x86 490 switch ((x86_fstcw () &amp; ~0xC00) &gt;&gt; 10) { 491 case 0: return 0; break; /* nearest */ 492 case 1: return 3; break; /* down */ 493 case 2: return 2; break; /* up */ 494 case 3: return 1; break; /* tozero */ 495 } 496 #endif 497 498 return -1; 499 } 500 [...] But the calls to x86call.asm for the x86_fldcw and x86_fstcw routines clashes with the -DNO_ASM directive........ Changing the compile recipe to this: setenv ABI 32 setenv CC cc setenv CXX CC setenv M4 /usr/local/bin/m4 cd /var/tmp rm -rf gmp-5.1.1 xz -dc /usr/local/src/gnu/gmp-5.1.1.tar.xz | gtar -xvf - cd gmp-5.1.1 ./configure --prefix=/usr/local \ --disable-assembly gmake /bin/perl -pe 's#HAVE_HOST_CPU_FAMILY_x86#HAVE_HOST_CPU_FAMILY_x86 &amp;&amp; ! defined (NO_ASM)#' -i tests/misc.c gmake check lets the gmake check finish and pass all tests for ABI32 with --disable-assembly The root cause lines (fixed): host:/var/tmp/gmp-5.1.1 root# grep -n FAMILY tests/misc.c 468:#if HAVE_HOST_CPU_FAMILY_x86 &amp;&amp; ! defined (NO_ASM) 489:#if HAVE_HOST_CPU_FAMILY_x86 &amp;&amp; ! defined (NO_ASM) ta, Mark. </pre> Mark Ashley 2013-05-15T07:39:52 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4050 <pre> yes. sorry, I reported this issue more than one month ago, and now I cannot reproduce it any more. Paul _______________________________________________ gmp-bugs mailing list gmp-bugs&lt; at &gt;gmplib.org http://gmplib.org/mailman/listinfo/gmp-bugs </pre> Zimmermann Paul 2013-05-14T15:09:53 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4049 <pre> when cross-compiling, GMP assumes the strnlen() function is not present on the target machine, and if it is present on the compilation machine, we get a conflict with the "static" declaration in printf/repl-vsnprintf.c. It seems this is the only similar issue with 5.1.1. Are you refering to the code, #if ! HAVE_STRNLEN static size_t strnlen (const char *s, size_t n) ... in printf/repl-vsnprintf.c? I don't understand the correlation of any problems with this code and cross-compilation. And if the (cross-) compilation environment is set up properly, wouldn't HAVE_STRNLEN be set correctly? </pre> Torbjorn Granlund 2013-05-14T13:47:19 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4048 <pre> On Wed, 2013-05-08 at 16:44 -0400, Torbjorn Granlund wrote: &gt; I think I now have a fix for the bug. The file mpn/x86_64/bd1/mul_1.asm &gt; really never ever worked properly for DOS64. &gt; This fixes the test failures on our machines. Thanks for the feedback. This bug indicated a flaw in our testing, since the bulldozer mpn_mul_1 was completely non-functional under the 64-bit Windoze ABI. We now test all x86 and x86-64 code from a fat build on the Windoze machine dos64.gmplib.org as well as a ELF ABI system. The results are reported as *-fake (it is based on providing a 'fake' cpuid overriding the real cpuid). </pre> Torbjorn Granlund 2013-05-10T12:22:21 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4047 <pre> &gt; Building gmp 5.1.1 using &gt; &gt; ./configure --host=x86_64-w64-mingw32 &gt; &gt; That's a quite bogus configuration, basically disabling CPU &gt; optimisation. This sent me chasing the bug in the wrong direction, &gt; since I assumed you where using a bulldozer config here. Is there a better way to tell configure to look for the x86_64-w64-mingw32 tools? The chef recommends CC=... CXX=... Torbjörn _______________________________________________ gmp-bugs mailing list gmp-bugs&lt; at &gt;gmplib.org http://gmplib.org/mailman/listinfo/gmp-bugs </pre> Torbjorn Granlund 2013-05-09T13:49:08 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4046 <pre> Great, I'll test this locally as well. Darin </pre> Darin Ohashi 2013-05-09T12:15:56 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4045 <pre> Is there a better way to tell configure to look for the x86_64-w64-mingw32 tools? Without that host, configure uses the cygwin tools, which I don't want. If I specify --host=bulldozer-w64-mingw32, then configure looks for a compiler called bulldozer-w64-mingw32, which doesn't exists so it falls back to cygwin gcc. Darin </pre> Darin Ohashi 2013-05-09T12:31:10 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4044 <pre> This fixes the test failures on our machines. Darin </pre> Darin Ohashi 2013-05-09T13:34:00 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4043 <pre>I can appreciate the nuances in GMP, it's not obvious though to casual builders such as myself what it needs (and doesn't need), hence the point of this discussion and putting it into the archives for google to find later. I'd have found it very useful three days ago :) Because my GMP packages will be downloaded and used by tens of thousands of others I might re-compile with ABI=64, --disable-assembly for SPARC and --enable-fat for x86, thereby providing the widest possible platform support. Speed isn't a big factor, portability is. Let me know if that seems outrageous. On Thu, May 9, 2013 at 2:37 AM, Torbjorn Granlund &lt;tg&lt; at &gt;gmplib.org&gt; wrote: </pre> Mark Ashley 2013-05-08T21:49:21 http://permalink.gmane.org/gmane.comp.lib.gmp.bugs/4042 <pre>I think I now have a fix for the bug. The file mpn/x86_64/bd1/mul_1.asm really never ever worked properly for DOS64. *** /tmp/extdiff.8kgEx_/gmp-main.6e8878f722f0/mpn/x86_64/bd1/mul_1.asmWed May 8 22:42:33 2013 --- /home/tege/prec/gmp-main/mpn/x86_64/bd1/mul_1.asmWed May 8 22:41:49 2013 *************** *** 54,58 **** IFDOS(`define(`r9', ``rdi'')') dnl IFDOS(`define(`n', ``%r8'')') dnl ! IFDOS(`define(`r8', ``r11'')') dnl ASM_START() --- 54,58 ---- IFDOS(`define(`r9', ``rdi'')') dnl IFDOS(`define(`n', ``%r8'')') dnl ! IFDOS(`define(`r8', ``rbx'')') dnl ASM_START() I am building gmp for 64 bit Windows using cygwin's x86_64-w64-mingw32 packages, (gcc version 4.5.3). The machine is an AMD Opteron 6272 running Windows Server 2008 R2 64 bit. Building gmp 5.1.1 using ./configure --host=x86_64-w64-mingw32 That's a quite bogus configuration, basically disabling CPU optimisation. This sent me chasing the bug in the wrong direction, since I assumed you where using a bulldozer config here. </pre> Torbjorn Granlund 2013-05-08T20:44:11 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.gmp.bugs