Re: GMP 6.1.2 t-count_zeros failure on ARM with assertions

[Vincent Lefevre]

On 2017-12-26 11:51:28 +0100, Niels Möller wrote:
> Hmm, I guess the problem is
> 
>   #define count_leading_zeros_gcc_clz(count,x)\
> do {  \
>   ASSERT ((x) != 0);  \
>   (count) = __builtin_clzll (x);  \
> } while (0)
> 
> in combination with 
> 
>   #define count_leading_zeros(count, x) count_leading_zeros_gcc_clz(count, x)
>   #define count_trailing_zeros(count, x) count_trailing_zeros_gcc_ctz(count, 
> x)
>   #define COUNT_LEADING_ZEROS_0 32
> 
> in the arm32 and arm64 parts of longlong.h.

Yes.

> diff -r 20cf1131dc94 longlong.h
> --- a/longlong.h  Thu Aug 31 01:00:02 2017 +0200
> +++ b/longlong.h  Tue Dec 26 10:59:24 2017 +0100
> @@ -535,7 +535,6 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype 
>  #endif /* defined(__ARM_ARCH_2__) ... */
>  #define count_leading_zeros(count, x)  count_leading_zeros_gcc_clz(count, x)
>  #define count_trailing_zeros(count, x)  count_trailing_zeros_gcc_ctz(count, 
> x)
> -#define COUNT_LEADING_ZEROS_0 32
>  #endif /* __arm__ */
>  
>  #if defined (__aarch64__) && W_TYPE_SIZE == 64
> @@ -586,7 +585,6 @@ extern UWtype __MPN(udiv_qrnnd) (UWtype 
>  #endif
>  #define count_leading_zeros(count, x)  count_leading_zeros_gcc_clz(count, x)
>  #define count_trailing_zeros(count, x)  count_trailing_zeros_gcc_ctz(count, 
> x)
> -#define COUNT_LEADING_ZEROS_0 64
>  #endif /* __aarch64__ */
>  
>  #if defined (__clipper__) && W_TYPE_SIZE == 32

I confirm that this fixes the problem.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

GMP 6.1.2 t-count_zeros failure on ARM with assertions

[Vincent Lefevre]

I've built GMP 6.1.2 with assertions:

  ./configure --enable-assert --prefix=$HOME/opt/gmp-6.1.2

on an old ARM VM (Debian squeeze). But I get the failure:

FAIL: t-count_zeros
===

t-count_zeros.c:31: GNU MP assertion failed: (n) != 0
FAIL t-count_zeros (exit status: 134)

I've added some printf's in the code, and this is due to:

#ifdef COUNT_LEADING_ZEROS_0
  check_clz (COUNT_LEADING_ZEROS_0, CNST_LIMB(0));
#endif

If GMP does a test with CNST_LIMB(0), I wonder why it has an
assertion (n) != 0. This is not consistent!

$ gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-8' 
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-4.4 --enable-shared --enable-multiarch 
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc 
--disable-sjlj-exceptions --enable-checking=release --build=arm-linux-gnueabi 
--host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.4.5 (Debian 4.4.5-8) 

$ uname -a
Linux ypig-arm 2.6.32-5-versatile #1 Wed Jan 12 23:05:11 UTC 2011 armv5tejl 
GNU/Linux

$ ./config.guess
arm9te-unknown-linux-gnueabi

$ ./configfsf.guess
armv5tejl-unknown-linux-gnueabi

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: register corruption under MS Windows / x86-64

[Vincent Lefevre]

On 2017-12-15 00:00:40 +0100, Torbjorn Granlund wrote:
>   It is a flaw in our testing setup that this calling convention breach is
>   not caught by the automated testing.  I will fix both bugs.  :-)
>   
> I have now pushed a fix for the mainline repo.  Testing would be
> appreciated!

One of those who saw the bug with MPFR 4 RC1 + GMP dev said that
everything seems fine with the latest GMP dev:

  https://sympa.inria.fr/sympa/arc/mpfr/2017-12/msg00067.html

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

register corruption under MS Windows / x86-64

[Vincent Lefevre]

There appears to be a bug in mpn/x86_64/fastsse/com-palignr.asm,
which is now used by the GMP trunk. If I understand correctly,
the optimized loop uses xmm6 and xmm7 without restoring their
values. This is correct under Linux, but not under MS Windows,
according to:

  
https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions

which says:

  In x86-64, Visual Studio 2008 stores floating point numbers in XMM6
  and XMM7 (as well as XMM8 through XMM15); consequently, for x86-64,
  user-written assembly language routines must preserve XMM6 and XMM7
  (as compared to x86 wherein user-written assembly language routines
  did not need to preserve XMM6 and XMM7). In other words,
  user-written assembly language routines must be updated to
  save/restore XMM6 and XMM7 before/after the function when being
  ported from x86 to x86-64.

Since the commit https://gmplib.org/repo/gmp/rev/069ff6facc35 [*]
(which enables this asm file), MS Windows users get obscure failures
in MPFR 4.0.0-rc1 (debugging shows a floating-point value becoming
NaN) under some conditions (depending on whether optimizations are
used, on output of debug information, and on whether the library is
shared or static...).

[*] https://sympa.inria.fr/sympa/arc/mpfr/2017-12/msg00045.html

More information here:

  https://sympa.inria.fr/sympa/arc/mpfr/2017-12/msg00051.html

and in earlier messages of the thread.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GNU MP 6.1.2 error undefined symbol __gmpn_invert_limb in test t-constants

[Vincent Lefevre]

On 2017-08-28 23:33:03 +0200, Niels Möller wrote:
> Vincent Lefevre <vinc...@vinc17.net> writes:
> > This only works if the user is root. If a non-root user wants to
> > install libraries in his home directory, the right solution is to
> > use LD_LIBRARY_PATH (since GCC doesn't use a run path by default).
> 
> You'd either use LD_LIBRARY_PATH, which is going to be a bit brittle
> when a build system or other script depends on using LD_LIBRARY_PATH for
> its own purposes,

They can preprend their own directories to $LD_LIBRARY_PATH.

> or compile the stuff needing the libraries with something like.
> 
>   LDFLAGS='-L $HOME/lib/ -Wl,-rpath,$HOME/lib'

which, in turn, may break things. For instance, MPFR uses LD_RUN_PATH
temporarily in its configure script. But if the user uses -rpath,
LD_RUN_PATH will be ignored. And I don't think we should re-implement
all the libtool machinery for the configure script to guess what
should work.

> Neither option is entirely painless, unfortunately.
> 
> In this particular case, it might work better if automake's test binary
> magic did use LD_LIBRARY_PATH and *pre*pended the .lib directory, but I
> guess it does things differently, either using -rpath or *a*ppending
> .lib. 

That's more a libtool thing than an automake one, AFAIK.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GNU MP 6.1.2 error undefined symbol __gmpn_invert_limb in test t-constants

[Vincent Lefevre]

On 2017-08-28 22:50:23 +0200, Niels Möller wrote:
> Dennis Clarke  writes:
> 
> > In some manner the pre-existing libs were getting in the way likely
> > because LD_LIBRARY_PATH=/usr/local/lib and thus the new libs in the
> > build_dir/.libs were not used.
> 
> LD_LIBRARY_PATH tends to override anything else. Don't use that for
> anything but to run specific binaries which need it.
> 
> Since this was a gnu/linux system, the usual way to make ld.so search
> /usr/local/lib is via files under /etc/ld.so.conf.d (even if that's
> system global, unlike LD_LIBRARY_PATH).

This only works if the user is root. If a non-root user wants to
install libraries in his home directory, the right solution is to
use LD_LIBRARY_PATH (since GCC doesn't use a run path by default).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: FreeBSD links wrong library for tests if one is installed in $prefix

[Vincent Lefevre]

On 2017-06-28 13:55:41 +0200, Torbjorn Granlund wrote:
> Emmanuel Thomé  writes:
> 
>   freebsd's ld, which is a venerable GNU binutils 2.17.50 dated 2007-07-50
>   (yes, I'm talking about the current freebsd), does not emit new dtags
>   (runpath vs rpath) by default.
>   
> Ouch, I hadn't noticed that.
> 
> Our test environment includes many (virtualised) fbsd systems but they
> might all have a non-archaic binutils installed in /usr/local.

Note also that the problem will be detected only if there is an
ABI-compatible GMP library installed under a non-default directory
(used as $prefix). Is this the case in your test environments?

> The fbsd developers' GNU/Linux envy is projected at GPL hate which in
> turn badly hurts their own system.

This is not fair. The current behavior is the same as various Linux
systems, including Debian until Jessie. AFAIK, this is the default
binutils behavior. The issue with FreeBSD is that there was a bug
in their dynamic loader and libtool regarded this bug as a feature
(instead of assuming that both behaviors could occur). After the fix
of this bug, things got wrong with libtool.

The old dtags are much better for "make check" without wrapper
scripts, as LD_LIBRARY_PATH isn't in the way. If only the new dtags
are supported in the future, then wrapper scripts should be made
mandatory (i.e. no -no-install).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: FreeBSD links wrong library for tests if one is installed in $prefix

[Vincent Lefevre]

On 2017-06-27 23:11:02 +0200, Emmanuel Thome wrote:
> On Tue, Jun 27, 2017 at 08:01:50PM +0200, Vincent Lefevre wrote:
> > On 2017-06-27 19:21:00 +0200, Emmanuel Thome wrote:
> > > gf2x-freebsd-110-amd64-test2 ~/gmp-6.1.2 $ objdump -x 
> > > ./tests/mpn/.libs/t-mul | egrep "(R.*PATH|NEEDED)"
> > >   NEEDED  libgmp.so.10
> > >   NEEDED  libc.so.7
> > >   RPATH   /tmp/inst/lib
> > 
> > libtool should have put the local dir in the run path too.
> > It's strange that it didn't do that.
> 
> freebsd's ld, which is a venerable GNU binutils 2.17.50 dated 2007-07-50
> (yes, I'm talking about the current freebsd), does not emit new dtags
> (runpath vs rpath) by default.

I meant either RPATH or RUNPATH (whatever is used by ld). Here it
would be RPATH. Under Debian jessie, here's what I got for MPFR:

  RPATH  
/home/vlefevre/software/mpfr-3.1/src/.libs:/home/vlefevre/debian8/gmp/k10/lib

/home/vlefevre/debian8/gmp/k10/lib was the current installation
in my home dir, and /home/vlefevre/software/mpfr-3.1/src/.libs is
the directory from the build tree. You should have got something
similar, i.e.

  RPATH  /home/ci/gmp-6.1.2/.libs:/tmp/inst/lib

> I'm skeptical about the intent to mention the current directory as a
> r(un)path as well. Are you sure it's ever done that way ?

Not the current directory, but the directory that contains the
library that has just been built.

> > > Prepending "env LD_LIBRARY_PATH_RPATH=1" before running scripts in e.g.
> > > make check or make tune would be a workaround, I suppose.
> > 
> > Generating a right RPATH would be a better solution.
> 
> What's your definition of "right" ?

See above.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

gmp_snprintf tries to allocate 18 EB on long strings

[Vincent Lefevre]

Consider the following program:

#include 
#include 

int main(void)
{
  int r;
  long n = -1;

  r = gmp_snprintf (NULL, 0, "%2147483600s%100s%ln", "", "", );
  printf ("%d %ld\n", r, n);
  return 0;
}

On my Debian/unstable x86_64 machine (GMP 6.1.2 provided by the Debian
package), I get after 273 seconds:

GNU MP: Cannot allocate memory (size=18446744071562067968)

Wow! 18 EB! Actually this is close to 2^64. I suspect a conversion
of a negative value to size_t as a consequence of an integer
overflow.

As a comparison, if I just use snprintf (glibc function), I get the
result -1 -1 after 12 seconds (the first value must be negative,
the second one may be regarded as unspecified due to the EOVERFLOW
failure).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: "make check" fails: undefined reference to `__gmpn_compute_powtab'

[Vincent Lefevre]

After a closer look, problem solved with "autoreconf".
IMHO, maintainer mode should be enabled by default.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: x86_64-w64-mingw32 test FAIL t-scanf.c:1477: GNU MP assertion failed: ret == (-1)

[Vincent Lefevre]

On 2017-03-30 10:52:33 +0100, Claude Heiland-Allen wrote:
> The failing source code is:
> 
>   /* EOF for no matching */
>   {
> char buf[128];
> ret = gmp_sscanf ("   ", "%s", buf);
> ASSERT_ALWAYS (ret == EOF);
> ret = fromstring_gmp_fscanf ("   ", "%s", buf);
> ASSERT_ALWAYS (ret == EOF);
> if (option_libc_scanf)
>   {
> ret = sscanf ("   ", "%s", buf);
> ASSERT_ALWAYS (ret == EOF);
> ret = fun_fscanf ("   ", "%s", buf, NULL);
> ASSERT_ALWAYS (ret == EOF);
>   }
>   }
> 
> Commenting out the asserts and 'if' and inserting debugging printf()
> statements gives:
> 
> gmp_sscanf() ret = 0
> fromstring_gmp_fscanf() ret = 0
> sscanf() ret = 0
  
> fun_fscanf() ret = 0

The initial issue is the 0 returned by sscanf(). Then GMP is consistent
with the C implementation.

Though the C standard may be ambiguous, 0 is not possible as a return
value. Thus this is a bug in the C library (or compiler).

If %s can match an empty sequence of non-white-space characters, then
the return value should be 1 (contrary to %[, there is no mention of
"nonempty" for %s in the text of the standard). Otherwise, this is an
input failure because the end of the input string is reached before
the %s matching:

  4  The fscanf function executes each directive of the format in turn.
 When all directives have been executed, or if a directive fails
 (as detailed below), the function returns. Failures are described
 as input failures (due to the occurrence of an encoding error or
 the unavailability of input characters), or matching failures (due
 to inappropriate input).

And in case of input failure before the first conversion has completed
(which is the case here), EOF is returned:

 16  The fscanf function returns the value of the macro EOF if an
 input failure occurs before the first conversion (if any) has
 completed. Otherwise, the function returns the number of input
 items assigned, which can be fewer than provided for, or even
 zero, in the event of an early matching failure.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: building gmp-6.1 for s390 (31-bit) w/asm disabled failing with undefined sdiv_qrnnd

[Vincent Lefevre]

On 2016-12-09 22:29:18 +0100, Torbjörn Granlund wrote:
> Right.  The longlong.h file is shared among several GNU programs, but I
> long ago stopped trying to keep GMP's version easily usable outside of
> GMP.
> 
> In particular, GMP's longlong.h requires various external functions, and
> the condition under which these are needed are part of the internals.
> 
> This is a MPFR problem.  It is unfixable in GMP.

I suppose that if one doesn't use the macros that depend on
GMP internals, there should be no problems. In particular,
udiv_qrnnd is not used, unless the user configured MPFR to use
the GMP internals, but then that's the user's own problems.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mpz reuse test takes too much time

[Vincent Lefevre]

On 2016-09-28 16:24:15 +0200, Torbjörn Granlund wrote:
> Vincent Lefevre <vinc...@vinc17.net> writes:
> 
>   But there may have been a temporary problem, as I now get:
>   
>   ./reuse  27.56s user 0.15s system 100% cpu 27.698 total
>   
> That's more in the expected range.  Amd bulldozers are not GMP speed
> demons, with their 1/4 mul throughput, but they are not that slow.

This seems consistent with the 4200.19 bogomips given by /proc/cpuinfo.

As a comparison, with a loaded Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz
(5588.28 bogomips) machine, I get 18.58s (8.50s if not loaded).

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Compile warnings

[Vincent Lefevre]

On 2016-02-06 17:03:34 +, Junges, Sebastian wrote:
> Dear developers,
> 
> We are successfully using gmp in several of our projects. Thanks for all the 
> efforts you put into the project.
> I’m fully aware that compilation time warnings are not the same as bugs, 
> however, I still would like to draw your attention to the following three 
> warnings I get during compilation of files including gmp.h.
> They prevent simple usage of -Werror.
> 
> /usr/local/include/gmp.h:2139:345: warning: equality comparison with 
> extraneous parentheses [-Wparentheses-equality]
>   do { mp_size_t __gmp_i; mp_limb_t __gmp_x; __gmp_i = (__gmp_ysize); if 
> (__gmp_i != 0) { if (__gmpn_add_n (__gmp_wp, __gmp_xp, __gmp_yp, __gmp_i)) { 
> do { if (__gmp_i >= (__gmp_xsize)) { (__gmp_c) = 1; goto __gmp_done; } 
> __gmp_x = (__gmp_xp)[__gmp_i]; } while __gmp_wp)[__gmp_i++] = (__gmp_x + 
> 1) & ((~ (static_cast (0))) >> 0)) == 0)); } } if ((__gmp_wp) != 
> (__gmp_xp)) do { mp_size_t __gmp_j; ; for (__gmp_j = (__gmp_i); __gmp_j < 
> (__gmp_xsize); __gmp_j++) (__gmp_wp)[__gmp_j] = (__gmp_xp)[__gmp_j]; } while 
> (0); (__gmp_c) = 0; __gmp_done: ; } while (0);

This one may be impossible to "fix". If I understand correctly, you
can produce such a warning with something like:

#define FOO (a == b)

while (FOO) { ... }

Due to how the C preprocessor works, extraneous parentheses may happen.
Emitting a warning in such a case is a bad idea.

In gmp.h, this probably comes from:

#define __GMPN_ADD(cout, wp, xp, xsize, yp, ysize)  \
  __GMPN_AORS (cout, wp, xp, xsize, yp, ysize, mpn_add_n,   \
   (((wp)[__gmp_i++] = (__gmp_x + 1) & GMP_NUMB_MASK) == 0))

The extraneous parentheses should be useless here if the __GMPN_AORS
macro is correctly written, though they may be regarded as safer.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs