GMP repository: "make" failure if yacc is not available

[Vincent Lefevre]

I'm trying to build GMP from its repository (18472:1040c6303455)
on a new machine, and "make" gives the following error:

make[3]: Entering directory '/home/vinc17/software/gmp/demos/calc'
test -f calc.c || /bin/sh ../../ylwrap calc.y y.tab.c calc.c y.tab.h `echo 
calc.c | sed -e s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s/c++$/h++/ -e 
s/c$/h/` y.output calc.output -- yacc -d 
../../ylwrap: 176: yacc: not found
make[3]: *** [Makefile:459: calc.c] Error 127

Is yacc a new requirement? If it is, it should be checked by the
configure script.

Note that neither yacc nor bison is mentioned as needed by "README.HG",
in case this is specific to the use of the hg repository.

-- 
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

inconsistent config.guess output and -mtune for westmere

[Vincent Lefevre]

With GMP 6.3.0:

krakatoa:~/software/gmp-6.3.0> ./config.guess
westmere-pc-linux-gnu
krakatoa:~/software/gmp-6.3.0> ./configure
checking build system type... westmere-pc-linux-gnu
checking host system type... westmere-pc-linux-gnu
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking ABI=64
checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64 ... yes
checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64  
-mtune=nehalem... yes
checking compiler gcc -O2 -pedantic -fomit-frame-pointer -m64 -mtune=nehalem  
-march=nehalem... yes
[...]

It uses -mtune=nehalem instead of -mtune=westmere.

According to configure.ac, the choice is apparently based on what
gcc 3.4 knows. But gcc 3.4 is very old...

-- 
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: major formatted output function bug with %c and the value 0

[Vincent Lefevre]

On 2024-03-25 18:13:22 +0100, marco.bodr...@tutanota.com wrote:
> Vincent, you did not confirm that this code worked for you, but I
> pushed it anyway.
> https://gmplib.org/repo/gmp/rev/4ac76064639e

Thanks. I'll look at it when I have some time.

-- 
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: lots of "undefined reference" from /bin/ld under Debian

[Vincent Lefevre]

On 2024-02-23 17:26:45 +0100, Marc Glisse wrote:
> On Fri, 23 Feb 2024, Vincent Lefevre wrote:
> 
> > On a Debian/unstable x86_64 (amd64) machine, I've configured
> > GMP 18465:7ecb3b2beea1 with
> > 
> >  ./configure --prefix=$HOME/opt/gmp-devel
> > 
> > but "make check" fails with:
> > 
> > /bin/ld: t-bswap.o: in function `main':
> > t-bswap.c:(.text.startup+0x29): undefined reference to `__gmpn_random'
> 
> I only checked Debian testing (I don't see any big pending update that looks
> related) and I don't see that error, make check runs fine.
> 
> When you say 18465:7ecb3b2beea1, I assume you got a mercurial checkout, and
> ran .bootstrap before configure?
> 
> Can you provide the relevant logs?

After various tries, the problem eventually disappeared after a
"make distclean". Perhaps a missing dependency?

-- 
Vincent Lefèvre  - 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

lots of "undefined reference" from /bin/ld under Debian

[Vincent Lefevre]

On a Debian/unstable x86_64 (amd64) machine, I've configured
GMP 18465:7ecb3b2beea1 with

  ./configure --prefix=$HOME/opt/gmp-devel

but "make check" fails with:

/bin/ld: t-bswap.o: in function `main':
t-bswap.c:(.text.startup+0x29): undefined reference to `__gmpn_random'
/bin/ld: ./.libs/libtests.a(refmpn.o): in function `refmpn_sublsh_n':
refmpn.c:(.text+0x2614): undefined reference to `__gmpn_lshift'
/bin/ld: refmpn.c:(.text+0x2628): undefined reference to `__gmpn_sub_n'
/bin/ld: ./.libs/libtests.a(refmpn.o): in function `refmpn_rsblsh_n':
refmpn.c:(.text+0x2864): undefined reference to `__gmpn_lshift'
/bin/ld: refmpn.c:(.text+0x2878): undefined reference to `__gmpn_sub_n'
/bin/ld: ./.libs/libtests.a(refmpn.o): in function `refmpn_rsh1add_n':
refmpn.c:(.text+0x2a11): undefined reference to `__gmpn_add_n'
/bin/ld: refmpn.c:(.text+0x2a27): undefined reference to `__gmpn_rshift'
/bin/ld: ./.libs/libtests.a(refmpn.o): in function `refmpn_rsh1sub_n':
refmpn.c:(.text+0x2ab1): undefined reference to `__gmpn_sub_n'
/bin/ld: refmpn.c:(.text+0x2ac7): undefined reference to `__gmpn_rshift'
/bin/ld: ./.libs/libtests.a(refmpn.o): in function `refmpn_redc_1':
refmpn.c:(.text+0x5e26): undefined reference to `__gmpn_add_n'
/bin/ld: ./.libs/libtests.a(refmpn.o): in function `refmpn_random':
refmpn.c:(.text+0x6111): undefined reference to `__gmpn_random'
/bin/ld: ./.libs/libtests.a(refmpn.o): in function `refmpn_random2':
refmpn.c:(.text+0x6121): undefined reference to `__gmpn_random2'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_tdiv_qr'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_gcd_1'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_cnd_sub_n'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_set_str'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_sqr_basecase'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_divrem_2'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_perfect_power_p'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_mod_1_1p'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_com'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_rootrem'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_div_q'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_mul_basecase'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_gcdext'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_cnd_swap'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_mod_1s_4p_cps'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_scan0'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_preinv_mod_1'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmp_jacobi_table'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_sub_nc'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_divexact_1'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_toom_interpolate_8pts'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_modexact_1c_odd'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_toom_interpolate_7pts'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_sqr'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_toom_interpolate_6pts'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_div_qr_2n_pi1'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_mul_n'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_submul_1'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_sqrlo'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_toom_interpolate_5pts'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_get_str'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_mod_1_1p_cps'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_gcd'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_mod_1s_2p_cps'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 
`__gmpn_mul'
/bin/ld: /home/vlefevre/software/gmp/.libs/libgmp.so: undefined reference to 

Re: crash on __gmpz_init

[Vincent Lefevre]

On 2024-01-22 15:01:24 +0100, Vincent Lefevre wrote:
> I'm just surprised that GCC doesn't emit any warning
> (even with -O2 -Wall -Wextra), as some pointers are obviously
> incorrect.

The missing warning seems clearly a bug in GCC (I get a warning in
similar code, but not for the combination of malloc() and a loop),
which I've just reported:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113540

-- 
Vincent Lefèvre  - 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: crash on __gmpz_init

[Vincent Lefevre]

On 2024-01-22 14:34:21 +0100, Torbjorn Granlund wrote:
> Note that there are several typos for the dimensions in the examples, so
> making sense of things is pretty hard.

Indeed,

  mpz_init( M[ lin*LINES +col] );

should be lin*COLS + col.

I suspect a buffer overflow due to that (the allocated memory
is too small).

I'm just surprised that GCC doesn't emit any warning
(even with -O2 -Wall -Wextra), as some pointers are obviously
incorrect.

-- 
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: crash on __gmpz_init

[Vincent Lefevre]

On 2024-01-22 11:51:21 +0100, Vincent Lefevre wrote:
> On 2024-01-22 11:02:21 +0100, Marc Glisse wrote:
> > Hello,
> > 
> >   mpz_class M[LINES][COLS];
> > 
> > you are trying to put an array with millions of elements on the stack, so
> > the stack overflows. Very large arrays need to be allocated on the heap in
> > C++ (new, malloc, or some wrapper like std::vector).
> 
> Note that the user has a segmentation fault in __gmpz_init for
> test2_mem.c too (tc_7000x5000), which uses malloc(). See the
> gdb output.

I can reproduce the issue, even with a much smaller array:

qaa:~> gcc -DLINES=70 -DCOLS=10 -DSC=1 test2_mem.c -lgmp -o test2_mem
qaa:~> ./test2_mem
allocating 700; size=16
malloc(): corrupted top size
zsh: IOT instruction (core dumped)  ./test2_mem

And with valgrind:

==649064== Memcheck, a memory error detector
==649064== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==649064== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==649064== Command: ./test2_mem
==649064== 
allocating 700; size=16
==649064== Invalid write of size 8
==649064==at 0x488B147: __gmpz_init (in 
/usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0)
==649064==by 0x109271: main (in /home/vinc17/test2_mem)
==649064==  Address 0x4ad8040 is 0 bytes after a block of size 11,200 alloc'd
==649064==at 0x48407B4: malloc (vg_replace_malloc.c:381)
==649064==by 0x109218: main (in /home/vinc17/test2_mem)
==649064== 
==649064== Invalid write of size 8
==649064==at 0x488B14E: __gmpz_init (in 
/usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0)
==649064==by 0x109271: main (in /home/vinc17/test2_mem)
==649064==  Address 0x4ad8048 is 8 bytes after a block of size 11,200 alloc'd
==649064==at 0x48407B4: malloc (vg_replace_malloc.c:381)
==649064==by 0x109218: main (in /home/vinc17/test2_mem)
==649064== 

valgrind: m_mallocfree.c:278 (mk_plain_bszB): Assertion 'bszB != 0' failed.
valgrind: This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata.  If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away.  Please try that before reporting this as a bug.


host stacktrace:
==649064==at 0x580429AA: show_sched_status_wrk (m_libcassert.c:406)
==649064==by 0x58042AC7: report_and_quit (m_libcassert.c:477)
==649064==by 0x58042C57: vgPlain_assert_fail (m_libcassert.c:543)
==649064==by 0x5804CA6C: mk_plain_bszB (m_mallocfree.c:278)
==649064==by 0x5804CA6C: mk_plain_bszB (m_mallocfree.c:276)
==649064==by 0x5804CA6C: get_bszB_as_is (m_mallocfree.c:301)
==649064==by 0x5804CA6C: get_bszB (m_mallocfree.c:313)
==649064==by 0x5804CA6C: get_next_b (m_mallocfree.c:432)
==649064==by 0x5804CA6C: vgPlain_arena_malloc (m_mallocfree.c:1806)
==649064==by 0x58004FE4: vgMemCheck_new_block (mc_malloc_wrappers.c:370)
==649064==by 0x580051CA: vgMemCheck_malloc (mc_malloc_wrappers.c:405)
==649064==by 0x5809A08B: do_client_request (scheduler.c:1956)
==649064==by 0x5809A08B: vgPlain_scheduler (scheduler.c:1519)
==649064==by 0x580E1B6C: thread_wrapper (syswrap-linux.c:101)
==649064==by 0x580E1B6C: run_a_thread_NORETURN (syswrap-linux.c:154)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 649064)
==649064==at 0x48407B4: malloc (vg_replace_malloc.c:381)
==649064==by 0x487A968: __gmp_default_allocate (in 
/usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0)
==649064==by 0x4891FD3: __gmpz_realloc (in 
/usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0)
==649064==by 0x489305E: __gmpz_set_si (in 
/usr/lib/x86_64-linux-gnu/libgmp.so.10.5.0)
==649064==by 0x1092CB: main (in /home/vinc17/test2_mem)
client stack range: [0x1FFEFFD000 0x1FFF000FFF] client SP: 0x1FFEFFF540
valgrind stack range: [0x1002CAA000 0x1002DA9FFF] top usage: 18792 of 1048576

-- 
Vincent Lefèvre  - 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: crash on __gmpz_init

[Vincent Lefevre]

On 2024-01-22 11:02:21 +0100, Marc Glisse wrote:
> Hello,
> 
>   mpz_class M[LINES][COLS];
> 
> you are trying to put an array with millions of elements on the stack, so
> the stack overflows. Very large arrays need to be allocated on the heap in
> C++ (new, malloc, or some wrapper like std::vector).

Note that the user has a segmentation fault in __gmpz_init for
test2_mem.c too (tc_7000x5000), which uses malloc(). See the
gdb output.

-- 
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: Archive has incorrect size

[Vincent Lefevre]

Hi,

On 2024-01-15 01:27:20 -0800, Rick Curry wrote:
> gmp xz library has size: 2,094,196  gmp-6.3.0.tar.xz
> 
> According to the front page of your website, https://gmplib.org/, the
> archive should be much smaller: 2,027,316. Attempted download from both
> listed sites. Other archives are similarly larger than their expected size.
> 
> Download the latest release of GMP
> 
> GMP 6.3.0 lz, 2020558 bytes xz, 2027316 bytes zstd, 2101289 bytes
[...]

It seems that the size wasn't updated with the new release.
I still have:

-rw-r--r-- 1 vlefevre users 2027316 2020-11-17 10:21:26 gmp-6.2.1.tar.xz

-- 
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: major formatted output function bug with %c and the value 0

[Vincent Lefevre]

Hi,

On 2023-12-13 20:03:13 +0100, marco.bodr...@tutanota.com wrote:
> It was changed in 2001, probably a workaround, because the comment was
> "Don't use sprintf return value (it's a pointer on SunOS 4)"
> https://gmplib.org/repo/gmp/rev/0889877bb94a

Note that there are similar issues in printf/repl-vsnprintf.c, and I
think that this is the cause of the MPFR failure with MS Visual C++
(vsnprintf is used by gmp_vasprintf).

This file was added on 26 Oct 2001, thus 2 months after 0889877bb94a.

-- 
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: major formatted output function bug with %c and the value 0

[Vincent Lefevre]

On 2023-12-03 20:19:10 +0100, Vincent Lefevre wrote:
> With GMP 6.3.0, the formatted output functions do not handle %c
> with the value 0 correctly. For gmp_sprintf, the return value is
> incorrect.

In printf/sprintffuns.c, function gmp_sprintf_format(), I suppose that

  vsprintf (buf, fmt, ap);
  ret = strlen (buf);

should actually be something like

  ret = vsprintf (buf, fmt, ap);
  if (ret < 0)
ret = 0;

to avoid issues due to non-terminating null characters (not tested).

But I'm wondering how an error is possibly detected. The comment is:

/* If vsprintf returns -1 then pass it upwards.  It doesn't matter that
   "*bufp" is ruined in this case, since gmp_doprint will bail out
   immediately anyway.  */

> For gmp_asprintf and gmp_vasprintf, this is either a buffer overflow
> (according to the GMP manual: "The block will be the size of the
> string and null-terminator.") or, in case this is an error in the
> GMP manual, possible memory corruption when freeing the allocated
> memory, if the custom memory allocation function cares about the
> size parameter.

This should be checked and the GMP manual should be fixed.

> 
> Testcase for gmp_sprintf:
> 
> 
> #include 
> #include 
> 
> static void test (int flag)
> {
>   char s[3] = { 1, 1, 1 };
>   int r;
> 
>   r = (flag ? sprintf : gmp_sprintf) (s, "%c", 0);
>   printf ("%4s: r = %d, s = { %d %d %d }\n",
>   flag ? "libc" : "gmp", r, s[0], s[1], s[2]);
> }
> 
> int main (void)
> {
>   test (0);
>   test (1);
>   return 0;
> }
> 
> 
> which currently gives:
> 
>  gmp: r = 0, s = { 0 0 1 }
> libc: r = 1, s = { 0 0 1 }
> 
> MPFR has various issues concerning %c with the value 0, but an
> attempt to fix them fails due to
> 
>   length = gmp_vasprintf (...);
> [...]
>   mpfr_free_str (s);
> 
> which is similar to GMP's tests/misc/t-printf.c file, which contains
> 
>   got_len = gmp_vasprintf (, fmt, ap);
> [...]
>   (*__gmp_free_func) (got, strlen(got)+1);
> 
> But replacing
> 
>   mpfr_free_str (s);
> 
> by
> 
>   mpfr_free_func (s, length + 1);
> 
> i.e. using the return value length instead of strlen(s), also fails.
> I suppose that this is related to the incorrect return value.

Well, the failure was due to another mpfr_free_func, no longer this
one (I've now completely fixed MPFR, I think).

-- 
Vincent Lefèvre  - 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

major formatted output function bug with %c and the value 0

[Vincent Lefevre]

With GMP 6.3.0, the formatted output functions do not handle %c
with the value 0 correctly. For gmp_sprintf, the return value is
incorrect. For gmp_asprintf and gmp_vasprintf, this is either a
buffer overflow (according to the GMP manual: "The block will be
the size of the string and null-terminator.") or, in case this
is an error in the GMP manual, possible memory corruption when
freeing the allocated memory, if the custom memory allocation
function cares about the size parameter.

Testcase for gmp_sprintf:


#include 
#include 

static void test (int flag)
{
  char s[3] = { 1, 1, 1 };
  int r;

  r = (flag ? sprintf : gmp_sprintf) (s, "%c", 0);
  printf ("%4s: r = %d, s = { %d %d %d }\n",
  flag ? "libc" : "gmp", r, s[0], s[1], s[2]);
}

int main (void)
{
  test (0);
  test (1);
  return 0;
}


which currently gives:

 gmp: r = 0, s = { 0 0 1 }
libc: r = 1, s = { 0 0 1 }

MPFR has various issues concerning %c with the value 0, but an
attempt to fix them fails due to

  length = gmp_vasprintf (...);
[...]
  mpfr_free_str (s);

which is similar to GMP's tests/misc/t-printf.c file, which contains

  got_len = gmp_vasprintf (, fmt, ap);
[...]
  (*__gmp_free_func) (got, strlen(got)+1);

But replacing

  mpfr_free_str (s);

by

  mpfr_free_func (s, length + 1);

i.e. using the return value length instead of strlen(s), also fails.
I suppose that this is related to the incorrect return value.

-- 
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: error from GMP_ASM_W32 when building with IBM Open XL C/C++ for AIX 17.1.1

[Vincent Lefevre]

On 2023-10-02 14:51:23 +0200, Vincent Lefevre wrote:
> I tried to build GMP 6.3.0 with openxlC on AIX (for testing) using
> 
>   ./configure --prefix=$HOME/gmp-openxlc 
> CC=/opt/IBM/openxlC/17.1.1/bin/ibm-clang_r CFLAGS=-O2
> 
> on cfarm119.cfarm.net (a.k.a. gcc119), but got the following
> warnings and error related to assembler:
[...]

and even if I use --disable-assembly, I still get these warnings and
error.

-- 
Vincent Lefèvre  - 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

error from GMP_ASM_W32 when building with IBM Open XL C/C++ for AIX 17.1.1

[Vincent Lefevre]

Hi,

I tried to build GMP 6.3.0 with openxlC on AIX (for testing) using

  ./configure --prefix=$HOME/gmp-openxlc 
CC=/opt/IBM/openxlC/17.1.1/bin/ibm-clang_r CFLAGS=-O2

on cfarm119.cfarm.net (a.k.a. gcc119), but got the following
warnings and error related to assembler:

[...]
checking for assembler label suffix... :
checking for assembler global directive... .globl
checking for assembler global directive attribute... 
checking if globals are prefixed by underscore... 0654-210 conftest.o is not 
valid in the current object file mode.
Use the -X option to specify the desired object mode.
unknown
configure: WARNING: +--
configure: WARNING: | Cannot determine global symbol prefix.
configure: WARNING: | /usr/bin/nm -B -X64 output doesn't contain a global data 
symbol.
configure: WARNING: | Will proceed with no underscore.
configure: WARNING: | If this is wrong then you'll get link errors referring
configure: WARNING: | to ___gmpn_add_n (note three underscores).
configure: WARNING: | In this case do a fresh build with an override,
configure: WARNING: | ./configure gmp_cv_asm_underscore=yes
configure: WARNING: +--
checking how to switch to read-only data section... .csect .text[PR]
checking for assembler .type directive... 
checking for assembler .size directive... 
checking for assembler local label prefix... configure: WARNING: "/usr/bin/nm 
-B -X64" failure
configure: WARNING: cannot determine local label, using default L
L
checking for assembler byte directive... .byte
checking how to define a 32-bit word... 0654-210 conftest.o is not valid in the 
current object file mode.
Use the -X option to specify the desired object mode.
configure: error: cannot determine how to define a 32-bit word

This error comes from the GMP_ASM_W32 acinclude.m4 macro.

config.log.gz attached.

-bash-5.1$ uname -a
AIX gcc119 3 7 00F9C1964C00

-bash-5.1$ /opt/IBM/openxlC/17.1.1/bin/ibm-clang_r --version
IBM Open XL C/C++ for AIX 17.1.1 (5725-C72, 5765-J18), version 17.1.1.2, clang 
version 15.0.0 (build 3948f09)
Target: powerpc-ibm-aix7.3.0.0
Thread model: posix
InstalledDir: /opt/IBM/openxlC/17.1.1/bin

-bash-5.1$ ./config.guess
powerpc-ibm-aix7.3.1.0

-bash-5.1$ ./configfsf.guess
-bash: ./configfsf.guess: The file access permissions do not allow the 
specified action.

Indeed, the permissions in the tarball are incorrect (see my other
bug report).

-bash-5.1$ sh ./configfsf.guess
powerpc-ibm-aix7.3.1.0

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


config.log.gz
Description: application/gzip
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

incorrect configfsf.guess permissions for GMP 6.3.0

[Vincent Lefevre]

In the gmp-6.3.0.tar.xz tarball:

-rw-r--r-- tege/wheel49936 2023-07-29 15:42:16 gmp-6.3.0/configfsf.guess

The execute permissions are missing. This yields the following error:

-bash-5.1$ ./configfsf.guess
-bash: ./configfsf.guess: The file access permissions do not allow the 
specified action.

One can use "sh ./configfsf.guess", but the GMP manual says

   * The output from running './config.guess', and from running
 './configfsf.guess' (might be the same).

-- 
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: Unsigned integer overflow in `toom_eval_pm2.c`

[Vincent Lefevre]

On 2023-09-04 09:52:23 +0200, marco.bodr...@tutanota.com wrote:
> Should the value ~0 be written as ~0U to be correctly assigned to an
> unsigned?

IMHO, this would be better as this would make the signedness of
the types more consistent (the goal being to have an unsigned int
for all these masks).

-- 
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: Unsigned integer overflow in `toom_eval_pm2.c`

[Vincent Lefevre]

On 2023-09-03 22:16:21 +0200, Niels Möller wrote:
> Andrew Teylu  writes:
> 
> >> I am not sure the arithmetic on unsigned types is what clang is unhappy
> >> about, though.  Perhaps it dislikes the xor with "neg", which is a
> >> signed variable.
> 
> I can't say precisely what implicit conversions happen according to the
> spec: Unsigned to signed is always well defined, but the other direction
> only if the converted value fits.

It is signed to unsigned that is always well defined, with the
usual modulo rule. For unsigned to signed, if the value doesn't
fit, the behavior is implementation-defined.

> It may also depend on whether or not
> mp_limb_t is larger than int.
> 
> Does it make any difference if you change the "1" constants to "1u" ?

k is already unsigned. So changing the constants in ((k & 1) - 1)
won't change anything.

I suppose that clang complains because of the conversion from unsigned
to signed (since neg is an int). But note that this is *not* an
integer overflow.

> I see no good reason to involve any signed values here, though. Maybe
> the variable neg, and the return value, should be changed to mp_limb_t,
> or at least unsigned int?

You should also document the possibles values and their meaning.

> > I guess maybe a different question is: what is that code supposed to
> > do? Is the intent to `xor` with `0x` if the `k` is even and
> > `xor` with `0` if the `k` is odd (i.e., it either flips all the bits
> > in the even case or leaves them in the odd case)?
> 
> I think intention is to conditionally flip all the bits. And in
> addition, neg should always be either all ones or all zeros.

In toom_couple_handling.c, it is just used like a boolean value.

In mpn/generic/toom63_mul.c, there is

  sign ^= abs_sub_add_n (v1, v3, pp, n + 1);

and abs_sub_add_n also uses int with the same meaning. This seems
consistent, but you would need to check wherever such values can
be combined.

-- 
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: Uninitialized memory bug found in /mpn/generic/mod_1_1.c

[Vincent Lefevre]

On 2023-08-31 17:03:12 +0200, marco.bodr...@tutanota.com wrote:
> Ciao,
> 
> 31 ago 2023, 16:30 da ku...@shaw.ca:
> 
> > 1) Edit line 248 mpn/generic/mp_limb_t pre[4]; into:
> >
> ~/src/gmp$ hg diff mpn/generic/
> diff -r 3ac5afa36be5 mpn/generic/mod_1.c
> --- a/mpn/generic/mod_1.c   Wed Nov 02 13:48:37 2022 +0100
> +++ b/mpn/generic/mod_1.c   Thu Aug 31 16:46:35 2023 +0200
> @@ -245,7 +245,7 @@
>     }
>    else
>     {
> - mp_limb_t pre[4];
> + mp_limb_t pre[4] = {-1, -1, -1, -1};
>   mpn_mod_1_1p_cps (pre, b);
>   return mpn_mod_1_1p (ap, n, b, pre);
>     }
> 

I don't think that this is sufficient for the test.
The code Brett mentioned is for MOD_1_1P_METHOD = 2.
So, in mpn/generic/mod_1_1.c, I also changed

# define MOD_1_1P_METHOD 1/* need to make sure this is 2 for asm testing */

to

# define MOD_1_1P_METHOD 2/* need to make sure this is 2 for asm testing */

and at the beginning of

mpn_mod_1_1p (mp_srcptr ap, mp_size_t n, mp_limb_t b, const mp_limb_t bmodb[4])

I added

  ASSERT (bmodb[2] != -1);

(if bmodb[2] is not set, this would fail).

Then I configured with

  ./configure --disable-assembly --enable-assert

to enable the code and the assert, then "make" and "make check".

But even with that, I don't get any 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: bug in __gmp_replacement_vsnprintf

[Vincent Lefevre]

On 2023-08-21 10:59:13 +0200, Paul Zimmermann wrote:
> here is a small program that exhibits the bug (for example on gcc231):
[...]

An OpenBSD 7 machine, and this is due to the fact that %n is
no longer supported by the system *printf functions, so that
GMP uses __gmp_replacement_vsnprintf.

See also in the archives:

https://gmplib.org/list-archives/gmp-bugs/2022-October/005200.html
https://gmplib.org/list-archives/gmp-bugs/2023-January/005230.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

Re: integer overflow in mini-gmp due to integer promotion

[Vincent Lefevre]

On 2023-07-19 22:08:24 +0200, Niels Möller wrote:
> Vincent Lefevre  writes:
> 
> > On 2023-07-19 21:24:03 +0200, Niels Möller wrote:
> >> I think that's needed, to be able to support any size of
> >> MINI_GMP_LIMB_TYPE. Something like
> >> 
> >> #define umullo_limb(u, v) \
> >>   (sizeof(mp_limb_t) >= sizeof(int)) ? (u)*(v) : (unsigned int)(u) * (v))
> >> 
> >> If I understand you correctly, the two multiplies in
> >> gmp_udiv_qrnnd_preinv and gmp_udiv_qr_3by2 are the only places where we
> >> need a mullo operation, i.e., producing the low limb of a limb product?
> >
> > These are the only ones that affect MPFR, but I haven't looked
> > at the whole code.
> 
> Can you try out the attached patch?

No problems when testing MPFR with MINI_GMP_LIMB_TYPE = long, int,
short and char, with -m64 and with -m32.

-- 
Vincent Lefèvre  - 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: integer overflow in mini-gmp due to integer promotion

[Vincent Lefevre]

On 2023-07-19 21:24:03 +0200, Niels Möller wrote:
> Vincent Lefevre  writes:
> 
> > ./configure --with-mini-gmp=/home/vlefevre/software/gmp/mini-gmp CC=gcc-13 
> > CFLAGS="-O2 -fsanitize=undefined -fno-sanitize-recover 
> > -DMINI_GMP_LIMB_TYPE=short"
> >
> > I get lots of failures in mini-gmp.c (I suspect that the errors were
> > hidden by some optimization in GCC 12 and before).
> 
> Interesting. It seems rather undocumented what settings of
> MINI_GMP_LIMB_TYPE are supported/tested. I can try to guess your
> motivation for using such a small size, but can you give a bit more
> context?

The goal is to try to find bugs in MPFR. With limbs of small size,
particular cases (such as some limbs being 0 or -1) could occur
more often.

> I think it's desirable to support setting MINI_GMP_LIMB_TYPE to long
> long (which would make sense, e.g., on 64-bit windows, where for some
> historical reasons long is still only 32 bits). Unconditionally casting
> to unsigned long would break that.

OK.

> > Otherwise the sizes of the types could be checked like in
> > gmp_umul_ppmm.
> 
> I think that's needed, to be able to support any size of
> MINI_GMP_LIMB_TYPE. Something like
> 
> #define umullo_limb(u, v) \
>   (sizeof(mp_limb_t) >= sizeof(int)) ? (u)*(v) : (unsigned int)(u) * (v))
> 
> If I understand you correctly, the two multiplies in
> gmp_udiv_qrnnd_preinv and gmp_udiv_qr_3by2 are the only places where we
> need a mullo operation, i.e., producing the low limb of a limb product?

These are the only ones that affect MPFR, but I haven't looked
at the whole code.

-- 
Vincent Lefèvre  - 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

integer overflow in mini-gmp due to integer promotion

[Vincent Lefevre]

Hi,

When I test MPFR with

./configure --with-mini-gmp=/home/vlefevre/software/gmp/mini-gmp CC=gcc-13 
CFLAGS="-O2 -fsanitize=undefined -fno-sanitize-recover 
-DMINI_GMP_LIMB_TYPE=short"

I get lots of failures in mini-gmp.c (I suspect that the errors were
hidden by some optimization in GCC 12 and before).

For instance:

cventin:...ftware/mpfr/tests> ./texceptions
mini-gmp.c:993:7: runtime error: signed integer overflow: 46604 * 61440 cannot 
be represented in type 'int'

This is a call to gmp_udiv_qrnnd_preinv, which has

#define gmp_udiv_qrnnd_preinv(q, r, nh, nl, d, di)  \
  do {  \
mp_limb_t _qh, _ql, _r, _mask;  \
gmp_umul_ppmm (_qh, _ql, (nh), (di));   \
gmp_add_ss (_qh, _ql, _qh, _ql, (nh) + 1, (nl));\
_r = (nl) - _qh * (d);  \
[...]

Here, both _qh and d have type mp_limb_t, which is an unsigned short.
Since this is a 16-bit type and int is on 32 bits, unsigned short is
promoted to int, which is now a signed integer type, hence the error.

Ditto in gmp_udiv_qr_3by2.

I suppose that the simplest solution would be to add a cast to
unsigned long, so that the multiplication is done in this type (and
the subtraction too as a consequence), as this should be the largest
MINI_GMP_LIMB_TYPE size... hoping that the compiler will optimize.

I've attached a patch.

On the following testcase, GCC generates the same code for i1 and i2
and for s1 and s2 (tested on 32-bit and 64-bit x86, on aarch64, and
on ppc64le):

unsigned int i1 (unsigned int a, unsigned int b, unsigned int c)
{
  return a - b * c;
}

unsigned int i2 (unsigned int a, unsigned int b, unsigned int c)
{
  return a - (unsigned long) b * c;
}

unsigned short s1 (unsigned short a, unsigned short b, unsigned short c)
{
  return a - b * c;
}

unsigned short s2 (unsigned short a, unsigned short b, unsigned short c)
{
  return a - (unsigned long) b * c;
}

Otherwise the sizes of the types could be checked like in
gmp_umul_ppmm.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff -r 73d9ef70d14f mini-gmp/mini-gmp.c
--- a/mini-gmp/mini-gmp.c	Wed Jul 19 11:44:37 2023 +0200
+++ b/mini-gmp/mini-gmp.c	Wed Jul 19 15:43:46 2023 +0200
@@ -177,7 +177,7 @@
 mp_limb_t _qh, _ql, _r, _mask;	\
 gmp_umul_ppmm (_qh, _ql, (nh), (di));\
 gmp_add_ss (_qh, _ql, _qh, _ql, (nh) + 1, (nl));		\
-_r = (nl) - _qh * (d);		\
+_r = (nl) - (unsigned long int) _qh * (d);\
 _mask = -(mp_limb_t) (_r > _ql); /* both > and >= are OK */		\
 _qh += _mask;			\
 _r += _mask & (d);			\
@@ -198,7 +198,7 @@
 gmp_add_ss ((q), _q0, (q), _q0, (n2), (n1));			\
 	\
 /* Compute the two most significant limbs of n - q'd */		\
-(r1) = (n1) - (d1) * (q);		\
+(r1) = (n1) - (unsigned long int) (d1) * (q);			\
 gmp_sub_ddmmss ((r1), (r0), (r1), (n0), (d1), (d0));		\
 gmp_umul_ppmm (_t1, _t0, (d0), (q));\
 gmp_sub_ddmmss ((r1), (r0), (r1), (r0), _t1, _t0);			\
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Whitespace after minus sign in mpz_set_str

[Vincent Lefevre]

On 2023-05-07 15:37:12 +0200, Fredrik Johansson wrote:
> However, mpz_set_str returns that the string is invalid when a space
> appears between the minus sign and the first digit. For example,
> 
> mpz_set_str(x, "- 123", 10)
> 
> does not work.

According to the GMP code (mpz/set_str.c), whitespace in the prefixes
0x/0X/0b/0B is not handled either.

-- 
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: issue with Microsoft compiler

[Vincent Lefevre]

On 2023-02-13 11:54:50 +0100, Marc Glisse wrote:
> Another option, if it is just the one place in gmp.h, would be to replace -X
> with 0-X (or the uglier ~X+1 but that does not seem necessary).

I find 0-X much uglier and it could even more deserve a warning due to
the use of mixed signed-unsigned arithmetic, which can often lead to
unexpected results on some platforms (e.g. whether long = int or not).

-- 
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: issue with Microsoft compiler

[Vincent Lefevre]

On 2023-02-13 10:20:07 +0100, Marc Glisse wrote:
> On Mon, 13 Feb 2023, Niels Möller wrote:
> > My view is that GMP simply depends on the required semantics of the C
> > specification. And negating mp_limb_t values is something that's done in
> > lots of places. I'm not aware of any workaround that wouldn't result in
> > an annoying amount of clutter.
> 
> I think changing it in public headers (gmp.h, gmpxx.h) is the important
> part, changing it in internal source files is less of an issue.

This is valid C, not even a coding style error, and this is a rather
common use of unsigned types, and sometimes necessary to avoid
undefined behavior (think of "-LONG_MIN", which needs to be done
in unsigned arithmetic, e.g. "- (unsigned long) LONG_MIN", because
-LONG_MIN is not representable as a signed long).

-- 
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

use of emphasize for math in the HTML GMP manual

[Vincent Lefevre]

GMP currently uses emphasize for math in the HTML GMP manual,
via @math{...} (and MPFR has copied to it). For instance, for
mpz_mul_2exp, one has "Set rop to op1 times 2 raised to op2." where
the whole "op1 times 2 raised to op2" is emphasized, i.e. typically
rendered in italics (or with a different color with lynx).

While I agree that variables should be in italics (@var ensures
that), having full text about math in italics seems wrong.

Or this should be fixed on the texinfo side (I really don't know
why it uses ):

  https://lists.gnu.org/archive/html/bug-texinfo/2022-10/msg00045.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

Re: GMP does not detect float exponent overflow while reading floating point numbers

[Vincent Lefevre]

On 2022-09-16 16:34:58 -0400, Eric Li wrote:
> Thanks to https://stackoverflow.com/a/73740744, looks like the cause of
> the bug it that GMP triggered a signed overflow in the following code
> (from https://gmplib.org/repo/gmp/file/feb796a7f683/mpf/set_str.c#l315)
[...]

I've given an answer:

  https://stackoverflow.com/a/73906883/3782797

This is not a bug. This is documented in the GMP manual:

  The 'mpf' functions and variables have no special notion of infinity
  or not-a-number, and applications must take care not to overflow the
  exponent or results will be unpredictable.

As Paul said, you should use GNU MPFR if you want well-defined
behavior.

-- 
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

Please change http://mpfr.org to https://www.mpfr.org/

[Vincent Lefevre]

Hi,

The GMP manual doc/gmp.texi currently has @url{http://mpfr.org}.
But mpfr.org is poorly handled by Inria (no certificate and the
redirection to https://www.mpfr.org/ does not always work,
possibly to a temporary URL like currently, as one obtains
mpfr.loria.fr). This URL should be changed to

  https://www.mpfr.org/

The http://mpfr.org URL in doc/projects.html should be updated too.

Thanks,

-- 
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: clang warning about mini-gmp.c when used in Emacs

[Vincent Lefevre]

On 2022-04-19 20:16:51 +0200, Niels Möller wrote:
> I've always liked gcc -Wall. I think it adheres to its design to warn
> only about things that (1) are prone to be errors, and (2) in the case
> that they aren't errors, are easy to clarify in a way that makes the
> compiler stop warning about them.
> 
> Use of -Werror, on the other hand, is something that I can't generally
> recommend. Imposing it on library users by default is certainly a bad
> idea. Using it when compiling tests that are part of configure is almost
> sure to break.
> 
> But it could make sense to enable in certain nightly builds with known
> compilers, if one has the ambition that the code should build without
> (certain) warnings in that configuration, and stay that way.

-Werror may be useful for developers in order to automatically find
potential errors in new code, but it may be necessary to disable some
errors.

I generally test MPFR with

  -Wall -Wold-style-declaration -Wold-style-definition -Wmissing-parameter-type 
-Wmissing-prototypes -Wmissing-declarations -Wmissing-field-initializers 
-Wimplicit-fallthrough -Wcast-function-type -Wcast-align=strict -Wwrite-strings 
-Wno-error=unused-function -Werror -fsanitize=undefined -fno-sanitize-recover

and

  -std=c90 -pedantic -Wall -Wold-style-declaration -Wold-style-definition 
-Wmissing-parameter-type -Wmissing-prototypes -Wmissing-declarations 
-Wmissing-field-initializers -Wimplicit-fallthrough -Wcast-function-type 
-Wcast-align=strict -Wwrite-strings -Wno-error=unused-function 
-Wno-error=overlength-strings -Werror

-- 
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: clang warning about mini-gmp.c when used in Emacs

[Vincent Lefevre]

On 2022-04-15 07:29:34 +0200, Niels Möller wrote:
> I have two minor comments on this proposed fix:
> 
> 1. Is the void cast really needed? Corresponding macros in gmp-impl.h
> are defined like
> 
>   #if WANT_ASSERT
>   #define ASSERT_CARRY(expr) ASSERT_ALWAYS ((expr) != 0)
>   #define ASSERT_NOCARRY(expr)   ASSERT_ALWAYS ((expr) == 0)
>   #else
>   #define ASSERT_CARRY(expr) (expr)
>   #define ASSERT_NOCARRY(expr)   (expr)
>   #endif

I'd say that a cast to void is better in order to ensure that
ASSERT_CARRY(expr) and ASSERT_NOCARRY(expr) have type void
whether WANT_ASSERT is defined or not, so that type issues
could be detected more easily.

> 2. I'm a bit uneasy about side effects in the argument to the standard
> assert macro, even with the NDEBUG ifdefs.

Ditto. It seems that the ISO C standard doesn't say anything if
NDEBUG not defined (the expression might be evaluated several
times, like with any macro).

> Alternative patch:
> 
> --- a/mini-gmp/mini-gmp.c Tue Feb 15 09:18:40 2022 +0100
> +++ b/mini-gmp/mini-gmp.c Fri Apr 15 07:20:40 2022 +0200
> @@ -90,6 +90,7 @@ see https://www.gnu.org/licenses/.  */
>  #define gmp_assert_nocarry(x) do { \
>  mp_limb_t __cy = (x);   \
>  assert (__cy == 0); \
> +(void) __cy;\
>} while (0)

I prefer this patch.

-- 
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: mail archives are lost

[Vincent Lefevre]

On 2022-02-21 08:50:09 +0100, Paul Zimmermann wrote:
> not sure this is the best place to report. Since November 2021, the
> archives of the GMP mailing lists are no longer available. This is
> a pity since those archives contain a lot of useful information
> (except this mail of course).

Actually that's since the lists were back on mi-January.

For -bugs and -devel, there is still:
  https://www.mail-archive.com/gmp-bugs@gmplib.org/maillist.html
  https://www.mail-archive.com/gmp-devel@gmplib.org/maillist.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

Re: Segmentation fault with mpz_inp_raw on gcc45

[Vincent Lefevre]

On 2021-09-15 17:34:01 +0200, Vincent Lefevre wrote:
> On 2021-09-15 17:05:42 +0200, Paul Zimmermann wrote:
> > sorry the test_dummy2.save is attached. It was generated by (under /bin/sh,
> > not /bin/bash):
> > 
> > echo -e "\n\r\n\r# this is a comment line and should be ignored" > 
> > test_dummy2.save
> 
> I can reproduce the segfault only with a 32-bit ABI.
> 
> read(3, "-e \n\r\n\r# this is a comment line "..., 4096) = 54
> mmap2(NULL, 224735232, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
> 0) = 0xea604000
> --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xca604012} ---
> 
> If I understand correctly, the read system call comes from the initial
> fread() to get the size, and the mmap2 comes from the allocation.

In mpz/inp_raw.c, I think that abs_csize*8 yields an integer overflow
on large sizes.

-- 
Vincent Lefèvre  - 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: Segmentation fault with mpz_inp_raw on gcc45

[Vincent Lefevre]

On 2021-09-15 17:05:42 +0200, Paul Zimmermann wrote:
> sorry the test_dummy2.save is attached. It was generated by (under /bin/sh,
> not /bin/bash):
> 
> echo -e "\n\r\n\r# this is a comment line and should be ignored" > 
> test_dummy2.save

I can reproduce the segfault only with a 32-bit ABI.

read(3, "-e \n\r\n\r# this is a comment line "..., 4096) = 54
mmap2(NULL, 224735232, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
= 0xea604000
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xca604012} ---

If I understand correctly, the read system call comes from the initial
fread() to get the size, and the mmap2 comes from the allocation.

-- 
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: Segmentation fault with mpz_inp_raw on gcc45

[Vincent Lefevre]

On 2021-09-15 16:13:55 +0200, Torbjorn Granlund wrote:
> I tried to reproduce this on several systems.  I failed; mpz_inp_raw
> returns 0 for me as it should.
> 
> I cannot be sure I got test_dummy2.save right.  I did include the line
> that asked to be ignored.  Should I have ignored it?  I added LF at each
> appparent line end, including the ignore line.

You may need a bigger file, as shown by strace output:

openat(AT_FDCWD, "test_dummy2.save", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=51, ...}) = 0
read(3, "-e\n\n# this is a comment line and"..., 4096) = 51
mmap(NULL, 761597952, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f267cd4a000
read(3, "", 761593856)  = 0

i.e. if there is any issue in GMP, the test_dummy2.save file is too
small as nothing is read from read(3, "", 761593856).

Paul should give more details.

-- 
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: Limitation of the mpz_get_str function

[Vincent Lefevre]

On 2021-02-16 14:22:20 +0100, Christophe Clavier wrote:
> I suggest to modify the type of i to long int or to unsigned long int.

long or unsigned long may still be on 32 bits, e.g. under MS Windows.

I think that a more appropriate type in the context of a string
(or more generally an array of char) would be size_t.

-- 
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: Arithmetic bug on ARM (STM 32 F4)

[Vincent Lefevre]

On 2021-01-22 13:29:13 +0100, Titouan Coladon wrote:
> I cannot run make check because of the cross-compilation.

I think that it would be a good idea to use an emulator to check the
GMP build. This should always be done. Compiler bugs are common.

-- 
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: Arithmetic bug on ARM (STM 32 F4)

[Vincent Lefevre]

Hi,

On 2021-01-22 11:59:43 +0100, Titouan Coladon wrote:
> it's indeed, gcc that must have a bug.
> 
> The older bare metal version: gcc-arm-none-eabi-7-2017-q4-major-linux is
> working properly.
> 
> Then the latest version : gcc-arm-none-eabi-8-2018-q4-major-linux,
> gcc-arm-none-eabi-9-2020-q2-update-x86_64-linux and
> gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux all have the issue.

Does "make check" fail? If it doesn't, perhaps a new test could be
added.

-- 
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: FAIL: t-printf on Debian sparc64 with gcc-10 patched for gcc bugid 97939

[Vincent Lefevre]

On 2020-12-06 08:23:40 +, Dennis Clarke wrote:
> Sadly the situation continues here on Debian sparc64 :

I suggest that you try with -fsanitize=undefined -fno-sanitize-recover
just in case an issue would be detected before the actual crash.

> I just go single stepping around madly for a while and that includes
> into the sources of glibc-2.31 and I simply got lost.  Is there an
> easier way to track this down?

You should try to reduce the code to a minimal testcase.

-- 
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: Debian Linux SPARC64 issue with FAIL t-printf (exit status: 139)

[Vincent Lefevre]

On 2020-11-23 01:00:30 +0100, Vincent Lefevre wrote:
> FYI, no failures on gcc202.fsffrance.org with
> 
>   ./configure ABI=64 --enable-cxx --disable-assembly --enable-shared 
> --enable-static --enable-fft
> 
> Linux gcc202 5.9.0-2-sparc64-smp #1 SMP Debian 5.9.6-1 (2020-11-08) sparc64 
> GNU/Linux
> 
> Also a Debian sid with
> 
> vinc17@gcc202:~$ gcc --version
> gcc (Debian 10.2.0-17) 10.2.0

But note that I get an ICE with UBsan. My bug report with a very
simple testcase:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939

-- 
Vincent Lefèvre  - 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: Debian Linux SPARC64 issue with FAIL t-printf (exit status: 139)

[Vincent Lefevre]

On 2020-11-22 13:16:45 -0500, Dennis Clarke wrote:
> After hours of running this in circles for both 6.2.0 and 6.2.1
> with both gcc 9.3.0 ( Debian 9.3.0-18 ) and also the latest
> gcc 10.2.0 (Debian 10.2.0-17) I can report that the test t-printf
> does fail every time. With a consistent configure :
> 
> ./configure ABI=64 --enable-cxx --prefix=/opt/bw
> --libdir=/opt/bw/lib --disable-assembly
> --enable-shared --enable-static --enable-fft

FYI, no failures on gcc202.fsffrance.org with

  ./configure ABI=64 --enable-cxx --disable-assembly --enable-shared 
--enable-static --enable-fft

Linux gcc202 5.9.0-2-sparc64-smp #1 SMP Debian 5.9.6-1 (2020-11-08) sparc64 
GNU/Linux

Also a Debian sid with

vinc17@gcc202:~$ gcc --version
gcc (Debian 10.2.0-17) 10.2.0

-- 
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: GMP bootstrap fails with Autoconf 2.69d

[Vincent Lefevre]

On 2020-11-16 10:29:13 +0100, Hans Åberg wrote:
> > On 16 Nov 2020, at 01:18, Vincent Lefevre  wrote:
> > If I understand correctly, the goal is to have the Reporting-Bugs.html
> > URL together with the e-mail address.
> 
> Yes, and such a feature is not supported.
> 
> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Initializing-configure.html

I can read:

  AC_PACKAGE_BUGREPORT, PACKAGE_BUGREPORT
Exactly bug-report, if one was provided. Typically an email
address, or URL to a bug management web page.

So I think that GMP is correct here.

Earlier it is said "The optional argument bug-report should be the
email to which users should send bug reports." but that's a "should"
so that one can expect thinks to work, in particular with the
AC_PACKAGE_BUGREPORT / PACKAGE_BUGREPORT description.

Note that URLs can contain commas (this occurs in practice, but
perhaps not for BTS URLs), so that if commas or other characters
are forbidden, this should be documented so that the URL is
written with such characters encoded.

Note for GMP: if the URL is accepted, wouldn't it be better to just
put the URL in order to make sure users read this page?

-- 
Vincent Lefèvre  - 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: GMP bootstrap fails with Autoconf 2.69d

[Vincent Lefevre]

On 2020-11-15 23:49:10 +0100, Hans Åberg wrote:
> One can also have an additional URL argument, which defines a variable 
> PACKAGE_URL:
> 
> AC_INIT(GNU MP, GMP_VERSION, [gmp-bugs@gmplib.org (see 
> https://gmplib.org/manual/Reporting-Bugs.html)], gmp, [https://gmplib.org/])

If I understand correctly, the goal is to have the Reporting-Bugs.html
URL together with the e-mail address.

-- 
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: uint_least32_t is in stdint.h not in inttypes.h

[Vincent Lefevre]

On 2020-11-15 22:21:18 +0100, Felix von Leitner wrote:
> I was trying to compile gmp with my libc, dietlibc, and got an error
> that uint_least32_t is not defined.
> 
> Well, it is defined, and as far as I can tell in the right header file,
> too: stdint.h.
> 
> However, gmp-impl.h reads as follows:
> 
>  155 #if HAVE_INTTYPES_H  /* for uint_least32_t */
>  156 # include 
>  157 #else
>  158 # if HAVE_STDINT_H
>  159 #  include 
>  160 # endif
>  161 #endif
> 
> Note that stdint.h is in the else clause. dietlibc has both
> inttypes.h and stdint.h.

But ISO C99 says:

  7.8 Format conversion of integer types 

  The header  includes the header  [...]

So, including  if present should be sufficient, and
this is what the above code does.

That said, for C99 implementations, the #if tests would be useless,
so that the above code is also designed for non-C99 implementations,
which may have  and  with a behavior different
from C99, i.e.  will not necessarily include 
(but this also means that  will not necessarily have
uint_least32_t).

> Proposed fix: Move the #if HAVE_STDINT_H outside the previous #if.

Indeed, including both headers independently (when they are available)
may be the best way to have a chance to get uint_least32_t.

-- 
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: with strict C99 the tests/mpz/convert.c needs #include

[Vincent Lefevre]

On 2020-11-09 10:14:37 +0100, Torbjorn Granlund wrote:
> Vincent Lefevre  writes:
> 
>   In the context of the call, the values will always be nonnegative
>   so that this is OK, but there is a risk that some future developer
>   might reuse this function in another context, where it would be
>   incorrect on platforms with signed char (in particular, there is
>   no warning in the comment).
> 
> Perhaps we could rename this function
> note_that_this_funtion_is_called_str_casecmp_and_not_strcasecmp, to
> avoid such looming disaster?  Or, to be more polite, perhaps
> please_note_that_this_funtion_is_called_str_casecmp_and_not_strcasecmp?

Since GMP developers are so smart, why does the test exist anyway?
Since GMP is expected to return the correct answer, it is not needed
to do the test.

Seriously, this function is used in a context to test the result of
mpz_get_str, and it is better to assume any kind of bug (which could
come from GMP or the compiler, for instance). In particular, do not
assume that the string returned by mpz_get_str necessarily consists
of valid digits. The consequence of a bug might be that some memory
location in the string is an invalid digit or is not explicitly set.
If this happens, the test tolower (c1) != tolower (c2) may be false
in such a case, so that the error may remain undetected. Something
like

  if (c1 < 0 || c2 < 0)
abort ();

would improve the test.

Moreover, there's something I don't understand. In the test,

   base = bsi % 62 + 1;

so that the base may be larger or equal to 37, but in such bases,
the case is significant, but it is not tested. I mean that with the
current test, you won't be able to distinguish "1a" from "1A".

-- 
Vincent Lefèvre  - 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: with strict C99 the tests/mpz/convert.c needs #include

[Vincent Lefevre]

On 2020-11-07 18:45:52 -0500, Dennis Clarke wrote:
> However the tests blow up due to :
> 
> convert.c:143:11: error: implicit declaration of function 'strcasecmp'
> is invalid in C99
> 
> So that is easy to fix.
> 
> ijiraq# diff -u ./tests/mpz/convert.c.orig ./tests/mpz/convert.c
> --- ./tests/mpz/convert.c.orig  2020-01-17 13:44:49.0 +
> +++ ./tests/mpz/convert.c   2020-11-07 22:51:36.823215000 +
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include  /* for strlen */
> +#include  /* for strcasecmp */
> 
>  #include "gmp-impl.h"
>  #include "tests.h"
> ijiraq#

strcasecmp is not part of C99. It should be better to convert both
strings to uppercase (with toupper) or lowercase (with tolower),
then do a usual comparison.

-- 
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: Patch: support callback on allocation overflow instead of calling abort()

[Vincent Lefevre]

On 2020-10-06 16:59:10 +0200, Niels Möller wrote:
> There are other approaches to avoid these crashes, e.g., I think the
> recent emacs integration uses a (configurable) limit on bignum size, and
> will raise an emacs exception long before hitting GMP's limits, and the
> emacs process can go on running with no issues.

I would say that in practice, you are likely to hit dynamic memory limits
(e.g., which depend on the other processes running on the machine) before
GMP's limits. So I'm wondering whether this would be useful.

-- 
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: Patch: support callback on allocation overflow instead of calling abort()

[Vincent Lefevre]

On 2020-10-06 11:51:29 +0200, Marc Glisse wrote:
> On Tue, 6 Oct 2020, Vincent Lefevre wrote:
> 
> > On 2020-10-06 04:41:42 +0100, Colin Caine wrote:
> > > This is used by Julia to raise an OutOfMemory exception rather than having
> > > the Julia process itself abort.
> > > 
> > > Others on stackoverflow, etc, have experienced similar problems with
> > > undesired aborts(), so this patch would probably be useful to a variety of
> > > users. (see:
> > > https://github.com/JuliaLang/julia/issues/8286#issuecomment-323500953)
> > > 
> > > More information is available here and in the linked issues and PRs:
> > > https://github.com/JuliaLang/julia/pull/31215
> > 
> > Since the function could have allocated memory for intermediate
> > computations, how do you avoid memory leaks?
> 
> You would need something like
> 
> https://gmplib.org/list-archives/gmp-devel/2014-December/003868.html

But this is only for C++ and only for temporary memory (while
normal allocation seems to be sometimes used, like in mpz/mul.c
with "wp = __GMP_ALLOCATE_FUNC_LIMBS (wsize);").

-- 
Vincent Lefèvre  - 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: Patch: support callback on allocation overflow instead of calling abort()

[Vincent Lefevre]

On 2020-10-06 04:41:42 +0100, Colin Caine wrote:
> This is used by Julia to raise an OutOfMemory exception rather than having
> the Julia process itself abort.
> 
> Others on stackoverflow, etc, have experienced similar problems with
> undesired aborts(), so this patch would probably be useful to a variety of
> users. (see:
> https://github.com/JuliaLang/julia/issues/8286#issuecomment-323500953)
> 
> More information is available here and in the linked issues and PRs:
> https://github.com/JuliaLang/julia/pull/31215

Since the function could have allocated memory for intermediate
computations, how do you avoid memory leaks?

-- 
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: overflow in mpz type with a simple mpz_add_ui

[Vincent Lefevre]

On 2020-09-21 21:17:36 +0200, Torbjorn Granlund wrote:
> Vincent Lefevre  writes:
> 
>   This is not properly documented, then. The manual says:
> 
>'mpz_add_ui', 'mpz_sub_ui', 'mpf_add_ui' and 'mpf_sub_ui' benefit
>from an in-place operation like 'mpz_add_ui(x,x,y)', since usually
>^^
>only one or two limbs of 'x' will need to be changed.  The same
>applies to the full precision 'mpz_add' etc if 'y' is small.  If
>'y' is big then cache locality may be helped, but that's all.
> 
>   Since this should be an in-place operation (as there is no carry),
>   an overflow is unexpected here.
> 
> Overflow here is a result of the mathmatical result.  Whether things are
> done "in place" or not is not part of it.

No, here this is not the result of the mathematical result. In my
example, this is just a consequence of GMP's implementation.

> But overflow might be flagged one limb too early for addition; instead
> of at 2^27-1 limbs for 32-bit hosts it might happen already at 2^27-2
> limbs.  I cannot say that's particularly bad.

Instead of flagging overflow before the addition, GMP should flag it
after, if it really occurs.

-- 
Vincent Lefèvre  - 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: overflow in mpz type with a simple mpz_add_ui

[Vincent Lefevre]

On 2020-09-21 18:16:15 +0200, Torbjorn Granlund wrote:
> Vincent Lefevre  writes:
> 
>   So the overflow occurs in "mpz_add_ui (z, z, 1);", though this
>   operation doesn't need a larger mpz_t and could even be done
>   in place: no carry occurs here, and note that a carry for a
>   huge number is very unlikely to occur.
> 
> No bug.  You're (presumably deliberately) dancing on the edge of mpz
> overflow.  The overflow detection flags some false positives, which is
> by design.

This is not properly documented, then. The manual says:

 'mpz_add_ui', 'mpz_sub_ui', 'mpf_add_ui' and 'mpf_sub_ui' benefit
 from an in-place operation like 'mpz_add_ui(x,x,y)', since usually
 ^^
 only one or two limbs of 'x' will need to be changed.  The same
 applies to the full precision 'mpz_add' etc if 'y' is small.  If
 'y' is big then cache locality may be helped, but that's all.

Since this should be an in-place operation (as there is no carry),
an overflow is unexpected here.

-- 
Vincent Lefèvre  - 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

overflow in mpz type with a simple mpz_add_ui

[Vincent Lefevre]

With GMP 6.2.0 (Debian's package libgmp10:i386) on x86_64 in the
32-bit ABI, i.e. when compiling with -m32, I get the following
error:

cventin:~> cat tst.c
#include 
#include 

int main (void)
{
  mpz_t z;

  mpz_init_set_ui (z, 17);
  mpz_mul_2exp (z, z, 0xffbc);
  printf ("OK\n");
  mpz_add_ui (z, z, 1);

  return 0;
}
cventin:~> gcc -m32 tst.c -o tst -lgmp
cventin:~> ./tst
OK
gmp: overflow in mpz type

So the overflow occurs in "mpz_add_ui (z, z, 1);", though this
operation doesn't need a larger mpz_t and could even be done
in place: no carry occurs here, and note that a carry for a
huge number is very unlikely to occur.

-- 
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

mini-gmp.h FILE test update from gmp.h

[Vincent Lefevre]

In mini-gmp/mini-gmp.h, concerning FILE tests:

/* This long list taken from gmp.h. */

but the list in GMP 6.2.0 and the current repository is not up-to-date.
See attached patch.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff -r 57547dbdd7d4 mini-gmp/mini-gmp.h
--- a/mini-gmp/mini-gmp.h   Fri Sep 11 01:15:37 2020 +0200
+++ b/mini-gmp/mini-gmp.h   Wed Sep 16 14:29:52 2020 +0200
@@ -295,7 +295,8 @@
   || defined (_MSL_STDIO_H)   /* Metrowerks */  \
   || defined (_STDIO_H_INCLUDED)  /* QNX4 */   \
   || defined (_ISO_STDIO_ISO_H)   /* Sun C++ */\
-  || defined (__STDIO_LOADED) /* VMS */
+  || defined (__STDIO_LOADED) /* VMS */\
+  || defined (__DEFINED_FILE) /* musl */
 size_t mpz_out_str (FILE *, int, const mpz_t);
 #endif
 
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: mpz_sizeinbase() bug

[Vincent Lefevre]

On 2020-08-19 10:39:01 +0200, Paul Zimmermann wrote:
>Dear Johannes,
> 
> if you read carefully the GMP documentation, you will see this is not a bug:
> 
>  -- Function: size_t mpz_sizeinbase (const mpz_t OP, int BASE)
>  Return the size of OP measured in number of digits in the given
>  BASE.  BASE can vary from 2 to 62.  The sign of OP is ignored, just
>  the absolute value is used.  The result will be either exact or 1
>  too big.  If BASE is a power of 2, the result is always exact.  If
>  OP is zero the return value is always 1.

IMHO, it's a bad thing to say that one returns something, and later
say that this can be inexact. It could be improved to something like:

  Return the size of OP measured in number of digits in the given
  BASE, or this size + 1.  BASE can vary from 2 to 62.  If BASE is
  a power of 2, the result is always the exact size.  The sign of
  OP is ignored, just the absolute value is used. If OP is zero the
  return value is always 1.

> If you want the exact size, use mpz_get_str() and strlen(),
> or mpz_ui_pow_ui() and mpz_cmp().

I would say that this is rather inefficient since the exact result
can generally be determined from the first few digits.

-- 
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: bug in longlong.h for aarch64 sub_ddmmss

[Vincent Lefevre]

On 2020-06-17 11:04:26 +0200, Niels Möller wrote:
> t...@gmplib.org (Torbjörn Granlund) writes:
> 
> > The two - signs ought to be ~, I think.  Let me think a buit more about 
> > that.
> 
> If I remember ARM conventions correctly, subtract with carry is defined
> as
> 
>   {cout, r} = a + ~b + cin

This is a - b - borrow, where the borrow is the complement of the
carry bit.

-- 
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: bug in longlong.h for aarch64 sub_ddmmss

[Vincent Lefevre]

On 2020-06-16 16:11:53 +0200, Vincent Lefevre wrote:
> Note that I'm rather surprised to see that the issue disappears
> if I add unrelated code. For instance, in the following testcase,
> with GCC 9.1.0 -O2, I get "h = 0x", which is
> incorrect, but if I define V, I get the correct "h = 0x0".

Defining V apparently disables some optimization, so that only
the "else" case of sub_ddmmss is used.

Note: in the tests, it is important to test the macro on constants
in order to test the "if" case.

-- 
Vincent Lefèvre  - 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: bug in longlong.h for aarch64 sub_ddmmss

[Vincent Lefevre]

On 2020-06-16 14:47:23 +0200, Torbjorn Granlund wrote:
> Vincent Lefevre  writes:
> 
>   On 2020-06-16 13:40:14 +0200, Torbjorn Granlund wrote:
>   > Vincent Lefevre  writes:
>   > 
>   >   #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
>   > do {  
> \
>   >   if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000)   
> \
>   > __asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" 
> \
>   >  : "=r,r" (sh), "=," (sl) 
> \
>   >  : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  
> \
>   >"r,Z"   ((UDItype)(al)), "rI,r" (-(UDItype)(bl)) 
> __CLOBBER_CC);\
>   >   else
> \
>   > __asm__ ("subs\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" 
> \
>   >  : "=r,r" (sh), "=," (sl) 
> \
>   >  : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  
> \
>   >"r,Z"   ((UDItype)(al)), "rI,r"  ((UDItype)(bl)) 
> __CLOBBER_CC);\
>   > } while(0);
>   > 
>   > The two - signs ought to be ~, I think.  Let me think a buit more about 
> that.
> 
>   Note that the "else" case, which doesn't have a - sign in its
>   arguments is affected too, AFAIK.
> 
> I cannot follow you here.
> 
> Are you saying that the asm in the else clause is broken too?
> Please explain.

Sorry, it seems OK (I thought that on (0,0), subs and adds would
be equivalent, but the carry out is actually different).

Note that I'm rather surprised to see that the issue disappears
if I add unrelated code. For instance, in the following testcase,
with GCC 9.1.0 -O2, I get "h = 0x", which is
incorrect, but if I define V, I get the correct "h = 0x0".

typedef unsigned int UDItype __attribute__ ((mode (DI)));
typedef unsigned long UWtype;
#define W_TYPE_SIZE 64
#define __GMP_DECLSPEC
#define __GMP_GNUC_PREREQ(maj, min) \
  ((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min))
#include 
#include "longlong.h"

int v = 0;

int main (void)
{
  volatile unsigned long u0 = 0x4000, r0 = 0x7ffd;
  unsigned long u, r, h, l;
  u = u0;
  r = r0;
  if (r < 0x8000)
r = 0x8000;
#ifdef V
  if (v)
fflush (stdout);
#endif
  umul_ppmm (h, l, r, r);
  sub_ddmmss (h, l, u, 0, h, l);
  printf ("h = 0x%lx\n", h);
  return 0;
}

-- 
Vincent Lefèvre  - 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: bug in longlong.h for aarch64 sub_ddmmss

[Vincent Lefevre]

On 2020-06-16 12:55:07 +0200, Vincent Lefevre wrote:
> In longlong.h from GMP 6.2.0:
> 
> #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
>   do {  \
> if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000)   \
>   __asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
>: "=r,r" (sh), "=," (sl) \
>: "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
>  "r,Z"   ((UDItype)(al)), "rI,r" (-(UDItype)(bl)) 
> __CLOBBER_CC);\
> else\
>   __asm__ ("subs\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
>: "=r,r" (sh), "=," (sl) \
>: "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
>  "r,Z"   ((UDItype)(al)), "rI,r"  ((UDItype)(bl)) 
> __CLOBBER_CC);\
>   } while(0);
> 
> I don't understand this code. For instance, on ah=al=bh=bl=0, you
> do adds(0,0), which unsets the carry. And since borrow = not(carry),
> the sbc(0,0) will return -1.

Here's a test without using MPFR:

#define W_TYPE_SIZE 64
#define __GMP_DECLSPEC
#define __GMP_GNUC_PREREQ(maj, min) \
  ((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min))
#include 
#include "longlong.h"

int main (void)
{
  unsigned long sh, sl;

  sub_ddmmss (sh, sl, 0, 0, 0, 0);
  printf ("%lx\n", sh);
  return 0;
}

-- 
Vincent Lefèvre  - 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

bug in longlong.h for aarch64 sub_ddmmss

[Vincent Lefevre]

Hi,

In longlong.h from GMP 6.2.0:

#define sub_ddmmss(sh, sl, ah, al, bh, bl) \
  do {  \
if (__builtin_constant_p (bl) && -(UDItype)(bl) < 0x1000)   \
  __asm__ ("adds\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
   : "=r,r" (sh), "=," (sl) \
   : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
 "r,Z"   ((UDItype)(al)), "rI,r" (-(UDItype)(bl)) 
__CLOBBER_CC);\
else\
  __asm__ ("subs\t%1, %x4, %5\n\tsbc\t%0, %x2, %x3" \
   : "=r,r" (sh), "=," (sl) \
   : "rZ,rZ" ((UDItype)(ah)), "rZ,rZ" ((UDItype)(bh)),  \
 "r,Z"   ((UDItype)(al)), "rI,r"  ((UDItype)(bl)) 
__CLOBBER_CC);\
  } while(0);

I don't understand this code. For instance, on ah=al=bh=bl=0, you
do adds(0,0), which unsets the carry. And since borrow = not(carry),
the sbc(0,0) will return -1.

This is consistent with what I observe in MPFR with

#define MPFR_NEED_LONGLONG_H
#include "mpfr-test.h"
#include "invsqrt_limb.h"

int main (void)
{
  mp_limb_t h, l;

  sub_ddmmss (h, l, 0x4000, 0, 0x4000, 0);
  printf ("%lx\n", h);
  return 0;
}

which outputs  instead of 0.

-- 
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

typos in a comment in longlong.h

[Vincent Lefevre]

Hi,

In longlong.h:

/* FIXME: Extend the immediate range for the low word by using both ADDS and
   SUBS, since they set carry in the same way.  Note: We need separate
   definitions for thumb and non-thumb to to th absense of RSC under thumb.  */
   
There are at least 3 typos in these few words. I suppose that this
should be:

   definitions for thumb and non-thumb due to the absence of RSC under thumb. */

-- 
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: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

[Vincent Lefevre]

On 2020-06-09 10:21:31 +0200, Marc Glisse wrote:
> On Tue, 9 Jun 2020, Niels Möller wrote:
> 
> > Marc Glisse  writes:
> > 
> > > On Sat, 6 Jun 2020, Mihai Preda wrote:
> > > 
> > > > I would rather suggest to support intmax_t and uintmax_t.
> > > 
> > > That's one possibility for C (and C++, although it is a bit more
> > > painful there), but not one that everyone agrees with. I think the
> > > majority in standard committees believes that those 2 types were a
> > > mistake,
> > 
> > Any reference for such discussions?
> 
> No, I didn't take notes, and not all discussions are public. A quick search
> gives one paper presented to the C committee on the topic
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2303.pdf

The proposed change is worse. For instance, this would mean that
mp_limb_t could be larger than uintmax_t. This is an issue when
doing computations mixing various integer types from libraries, for
which one does not know their sizes. Or perhaps typeof could be the
solution, together with the ability to select the signedness of an
arbitrary integer type.

-- 
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: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

[Vincent Lefevre]

On 2020-06-08 22:32:25 +0200, Marc Glisse wrote:
> On Sat, 6 Jun 2020, Mihai Preda wrote:
> 
> > At this point the C++ compiler on windows (where long is 32-bit)
> > reports errors, see at the end. The problem is that the set of
> > constructors does not include one taking a 64-bit integer:
> 
> The issue is that:
> 1) the C++ interface follows the C interface
> 2) the C interface is still C89 (no long long)
> 3) Microsoft chose an absurd ABI for win64 (32bit long)
> 
> 3) is unlikely to change, we could change 1) but I'd rather not. The most
> likely evolution is about 2), at some indeterminate point in the future
> (hopefully not too far).

Couldn't the C interface *optionally* support more than C89?

> On Sat, 6 Jun 2020, Vincent Lefevre wrote:
> 
> > There's the same issue with 32-bit architectures, whatever the OS.
> 
> Indeed. And many users would also appreciate interoperability with
> int128_t (or whatever name it uses on their platform).

But isn't the support for 128-bit integers incomplete (i.e. not all
operations required by ISO C for an integer type are implemented)?

> > I would rather suggest to support intmax_t and uintmax_t.
> 
> That's one possibility for C (and C++, although it is a bit more painful
> there), but not one that everyone agrees with. I think the majority in
> standard committees believes that those 2 types were a mistake, in
> particular because they are 64 bits on platforms that now have a 128 bit
> type, but cannot change intmax_t as that would break the ABI.

I think that the first reason is that the support for 128-bit integers
is incomplete.

> Still, it isn't a bad choice for a large builtin integer type.

Anyway you don't introduce a new large builtin integer type everyday.
ABI breakages are annoying, but when they are rare, this could be
acceptable. Moreover, I suspect that very few libraries/applications
would be affected by a change of (u)intmax_t. And these are those
that would benefit from such a change.

-- 
Vincent Lefèvre  - 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: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

[Vincent Lefevre]

On 2020-06-06 14:28:21 +1000, Mihai Preda wrote:
> I'm using libgmp-dev 6.1.2 on Ubuntu myself, but the bug report
> concerns an unspecified version of GMP on Windows. I have reasons to
> suspect the bug is valid for the most recent GMP. Clear cause analysis
> and proposed solution is included.
> 
> I'm not a Windows user myself. I develop an open-source app that users
> are compiling, among others, on Windows with mingw or other c++
> compilers on windows. A common habit of these c++ compilers on windows
> is to have 32-bit long.

There's the same issue with 32-bit architectures, whatever the OS.

> In my app I construct a mpz_class from a 64-bit unsigned integer, like this:
> uint64_t h = ...;
> mpz_class{h};
> 
> At this point the C++ compiler on windows (where long is 32-bit)
> reports errors, see at the end. The problem is that the set of
> constructors does not include one taking a 64-bit integer:
> 
> #define __GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS\
>   __gmp_expr(signed char c) { init_si(c); }\
>   __gmp_expr(unsigned char c) { init_ui(c); }\
>   __gmp_expr(signed int i) { init_si(i); }\
>   __gmp_expr(unsigned int i) { init_ui(i); }\
>   __gmp_expr(signed short int s) { init_si(s); }\
>   __gmp_expr(unsigned short int s) { init_ui(s); }\
>   __gmp_expr(signed long int l) { init_si(l); }\
>   __gmp_expr(unsigned long int l) { init_ui(l); }\
>   __gmp_expr(float f) { init_d(f); }\
>   __gmp_expr(double d) { init_d(d); }
> 
> Among all in the list above, none takes a uint64_t or int64_t.
> 
> The fix could consist in having these constructors take int64_t
> instead of long int, etc. I.e. take explicitly-sized typed instead of
> the "long" which is variable-size.

I would rather suggest to support intmax_t and uintmax_t.

-- 
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: GMP 6.2 error

[Vincent Lefevre]

On 2020-04-01 09:45:18 -0400, Dennis Clarke wrote:
> On 2020-03-30 16:57, Torbjörn Granlund wrote:
> > rodriguez-murias  writes:
> > 
> >When i make install :
> > 
> >/usr/bin/mkdir: cannot create directory ‘/usr/local/share/info’: 
> > Permission denied
> > 
> > The inability to write into system directories as a non-root user is not
> > due to a problem with GMP.
> > 
> > You might want to grab a book on Unix and read the first few chapters.
> > 
> > 
> 
> Oh that was brutal and funny. We all need a laugh these days.
> 
> Perhaps better to suggest to the guy :
> 
> ls -lad /usr/local /usr/local/share
> 
> Then that will give him a hint.
> 
> Thanks for the laugh :)

Seriously, I think that the default prefix is non-sense. But this is
not a GMP issue either, rather an autoconf issue.

-- 
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: Having trouble building the library...

[Vincent Lefevre]

On 2020-03-05 22:30:51 +0100, Torbjorn Granlund wrote:
> D Lee  writes:
> 
>   *These are my steps:*
>   Downloaded and unpacked.
>   mkdir gmp-obj *outside* of the source tree.
>   cd gmp-obj
>   ../gmp-6.2.0/gmp-6.2.0/configure >> configure.log 2>&1 (see attached
>   configure.log file)
>   make check >> make-check.log 2>&1 (see attached make-check.log)
> 
> You forgot the plain "make" step.

Shouldn't "make check" build the required dependencies?
In MPFR, one can run "make check" without "make" first.

-- 
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: assertion failure in snprntffuns.c:79 for i686-w64-mingw32

[Vincent Lefevre]

On 2020-01-11 16:33:30 +0100, Marco Bodrato wrote:
> Ciao,
> 
> Il Ven, 10 Gennaio 2020 5:04 pm, Vincent Lefevre ha scritto:
> > On 2020-01-10 16:27:31 +0100, Marco Bodrato wrote:
> >> Can you please try with the development version?
> 
> > I get the following error:
> 
> > gmp_vsnprintf return value wrong
> 
> ... because there was an error in the process of cross-compilation...
> 
> > Is there a way to tell GMP's configure that vsnprintf is missing,
> > so that HAVE_VSNPRINTF is not defined?
> 
> Configure should check for it, but checking is not possible for
> cross-compilations. Should we add an option for this case?

Perhaps.

> It would be nice if the autotools give support for an optional "emulation
> environment", for a better configuration and an easier testing process...

I wonder why the #define's in config.h are not protected by #ifndef,
so that the user could set the value to 0. I mean that the general
form for macros set by default should have been:

#ifndef HAVE_VSNPRINTF
#define HAVE_VSNPRINTF 1
#elif HAVE_VSNPRINTF == 0
#undef HAVE_VSNPRINTF
#endif

FYI, about the snprintf bug in MinGW:

  https://sourceforge.net/p/mingw-w64/bugs/709/
  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000101

-- 
Vincent Lefèvre  - 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: assertion failure in snprntffuns.c:79 for i686-w64-mingw32

[Vincent Lefevre]

On 2020-01-10 16:27:31 +0100, Marco Bodrato wrote:
> This code was changed.
> 
> https://gmplib.org/repo/gmp/rev/d6b57abdad8e
> 
> Can you please try with the development version?

I get the following error:

FAIL: t-printf
==

gmp_vsnprintf return value wrong
  fmt   |%Mu|
  bufsize   2
  got   |12!7|
  want  |1|
  want full |127|
  ret   -1
  want_len  3
FAIL t-printf.exe (exit status: 3)

Note: The issue can be detected with the absence of \0 just before
the sentinel (but a \0 should be written there before the call to
make sure...).

But I now think that this is a bug that should be fixed in MinGW
since the intended behavior now seems to conform to the C standard.
FYI, the __USE_MINGW_ANSI_STDIO macro is now internal and should
no longer be used:

  
https://fr.osdn.net/projects/mingw/lists/archive/users/2019-January/000199.html

Is there a way to tell GMP's configure that vsnprintf is missing,
so that HAVE_VSNPRINTF is not defined?

BTW, I still notice in printf/vasprintf.c:

  ret = vsnprintf (d->buf + d->size, space, fmt, ap);
  if (ret == -1)
{
  ASSERT (strlen (d->buf + d->size) == space-1);
  ret = space-1;
}

-- 
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: assertion failure in snprntffuns.c:79 for i686-w64-mingw32

[Vincent Lefevre]

On 2020-01-10 08:44:13 +0100, Niels Möller wrote:
> Vincent Lefevre  writes:
> 
> > Under Debian/unstable, I've configured GMP with:
> >
> >   ./configure --host=i686-w64-mingw32 --disable-shared --enable-assert
> >
> > but "make check LOG_COMPILER=wine" gives:
> >
> > FAIL: t-printf
> > ==
> >
> > snprntffuns.c:79: GNU MP assertion failed: strlen (d->buf) == avail-1
> > FAIL t-printf.exe (exit status: 3)
> >
> > The failing code is
> >
> >   ret = vsnprintf (d->buf, avail, fmt, ap);
> >   if (ret == -1)
> > {
> >   ASSERT (strlen (d->buf) == avail-1);
> >   ret = avail-1;
> > }
> 
> Does it make a difference if you add CPPFLAGS=-D__USE_MINGW_ANSI_STDIO
> to the configuration?

I get no failures.

> > I don't understand the ASSERT. A return value of -1 means an output
> > error, so that you cannnot deduce anything about the contents stored
> > in d->buf.
> 
> Non-standard versions of snprintf returned -1 for truncation (including
> old glibc, and likely windows libc too). And the way I read the ASSERT,
> it says that truncation is the only expected reason for vsnprintf to
> return -1. What was fmt? It would be helpful to understand the reason
> for the -1 return in the failing case.

Here's what I get for i = 3 to 7:

i = 3, limb = 7 (1)
avail = 2, fmt = "%lu", ret = 1, buf = "7"

i = 4, limb = 15 (1)
avail = 2, fmt = "%lu", ret = 2, buf = "15!"

i = 5, limb = 31 (1)
avail = 2, fmt = "%lu", ret = 2, buf = "31!"

i = 6, limb = 63 (1)
avail = 2, fmt = "%lu", ret = 2, buf = "63!"

i = 7, limb = 127 (1)
avail = 2, fmt = "%lu", ret = -1, buf = "12!7"

So, one gets a truncation because avail = 2 is too small for 127,
and like with old glibc, one gets ret = -1. GMP expects that a \0
at the end is written in this case, and perhaps old glibc did, but
not mingw.

Note that the "7" after the sentinel is just old data. If I add

  d->buf[avail+1] = '\0';

before the

  ret = vsnprintf (d->buf, avail, fmt, ap);

I get:

avail = 2, fmt = "%lu", ret = -1, buf = "12!"

So, without -D__USE_MINGW_ANSI_STDIO, this is non-conforming (perhaps
for compatibility if vsnprintf was implemented in MS Windows before
it got standardized in ISO C99). I think that a fix should be easy:
write a \0 before the sentinel, and if ret = -1 and this \0 has been
replaced by vsnprintf, this probably means truncation.

-- 
Vincent Lefèvre  - 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

assertion failure in snprntffuns.c:79 for i686-w64-mingw32

[Vincent Lefevre]

Under Debian/unstable, I've configured GMP with:

  ./configure --host=i686-w64-mingw32 --disable-shared --enable-assert

but "make check LOG_COMPILER=wine" gives:

FAIL: t-printf
==

snprntffuns.c:79: GNU MP assertion failed: strlen (d->buf) == avail-1
FAIL t-printf.exe (exit status: 3)

The failing code is

  ret = vsnprintf (d->buf, avail, fmt, ap);
  if (ret == -1)
{
  ASSERT (strlen (d->buf) == avail-1);
  ret = avail-1;
}

I don't understand the ASSERT. A return value of -1 means an output
error, so that you cannnot deduce anything about the contents stored
in d->buf.

The first error occurs in check_limb

  s = mpz_get_str (NULL, 10, z);
  check_one (s, "%Mu", limb);
  (*__gmp_free_func) (s, strlen (s) + 1);

for i = 7, i.e. with limb = 127.

Note that config.h contains

/* Define to 1 if you have the `vsnprintf' function and it works properly. */
#define HAVE_VSNPRINTF 1

-- 
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: Latest commit introduces undefined behavior in hgcd2.c

[Vincent Lefevre]

On 2019-09-18 21:20:41 +0200, Torbjorn Granlund wrote:
> Guido Vranken  writes:
> 
>   My bignum fuzzer running at OSS-Fuzz came up with this:
> 
>   hgcd2.c:223:42: runtime error: shift exponent 64 is too large for
>   64-bit type 'mp_limb_t' (aka 'unsigned long')
>   #0 0x76a4db in div2 /src/libgmp/mpn/hgcd2.c:223:42
>   #1 0x769684 in __gmpn_hgcd2 /src/libgmp/mpn/hgcd2.c:372:18
>   #2 0x74ac55 in __gmpn_gcd /src/libgmp/mpn/gcd.c:200:11
>   #3 0x73c209 in __gmpz_gcd /src/libgmp/mpz/gcd.c
> 
>   Introduced in commit https://gmplib.org/repo/gmp/rev/f044264e2fe9
> 
> I think it is a false positive.  The result of the shifted value is
> masked when the shift count is not in range.

If the shift count is not in range, the behavior is undefined,
whatever you do with the "result". Having such undefined behavior
is a bug, as the compiler can do some optimization, such as
considering this as dead code. This is different from the case
where you have implementation-defined behavior.

-- 
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

failure to detect format of `double' on MS-Windows

[Vincent Lefevre]

Hi,

With 17862:b1ea8c11ae1e, I get:

$ ./configure '--host=i586-mingw32msvc' '--disable-shared' 
'host_alias=i586-mingw32msvc'
[...]
checking format of `double' floating point... od: conftest: No such file or 
directory
od: conftest: No such file or directory
unknown 
configure: WARNING: Could not determine float format.
configure: WARNING: Conversions to and from "double" may be slow.
[...]

One needs to change "conftest" to "conftest$EXEEXT".
Patch attached.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
diff -r b1ea8c11ae1e acinclude.m4
--- a/acinclude.m4  Wed Sep 04 06:18:08 2019 +0200
+++ b/acinclude.m4  Wed Sep 04 15:15:00 2019 +0200
@@ -3316,7 +3316,7 @@
   return 0;
 }]
 EOF
-gmp_compile="$CC $CFLAGS $CPPFLAGS conftest.c -o conftest >_FD_CC 2>&1"
+gmp_compile="$CC $CFLAGS $CPPFLAGS conftest.c -o conftest$EXEEXT >_FD_CC 
2>&1"
 if AC_TRY_EVAL(gmp_compile); then
 cat >conftest.awk <<\EOF
 [
@@ -3469,11 +3469,11 @@
 }
 ]
 EOF
-  gmp_cv_c_double_format=`od -b conftest | $AWK -f conftest.awk`
+  gmp_cv_c_double_format=`od -b conftest$EXEEXT | $AWK -f conftest.awk`
   case $gmp_cv_c_double_format in
   unknown*)
-echo "cannot match anything, conftest contains" >_FD_CC
-od -b conftest >_FD_CC
+echo "cannot match anything, conftest$EXEEXT contains" >_FD_CC
+od -b conftest$EXEEXT >_FD_CC
 ;;
   esac
 else
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: two tests fail for 6.1.2 on RISC-V rc64imafdc FreeBSD

[Vincent Lefevre]

On 2019-07-29 00:39:09 -0400, Dennis Clarke wrote:
> FAIL: reuse
> ===
> 
> ../../../gmp-6.1.2/test-driver: ./reuse: Exec format error
> FAIL reuse (exit status: 126)
> 
> FAIL: t-cmp_z
> =
> 
> ../../../gmp-6.1.2/test-driver: ./t-cmp_z: Exec format error
> FAIL t-cmp_z (exit status: 126)

Since the format of the generated binary is incorrect, that's
probably a compiler or linker bug. What "file reuse" says?
Try also things like "nm reuse". Is this reproducible?

-- 
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: not really a bug but somewhat odd : checking compiler /usr/local/bin/gcc8 ... no, mpn_lshift_com

[Vincent Lefevre]

On 2019-07-28 12:44:55 +0200, Vincent Lefevre wrote:
> On 2019-07-28 06:12:06 -0400, Dennis Clarke wrote:
> > configure:6813: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest
> > Abort trap (core dumped)
> 
> I don't know in your case, but I fear that this program is buggy.
[...]

You can try the attached patch in case this would be the issue.
This could also solve invisible failures (as occurring inside
configure) in other cases.

-- 
Vincent Lefèvre  - 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)
diff -r 36b5993aefae acinclude.m4
--- a/acinclude.m4  Sat Jul 13 22:25:31 2019 +0200
+++ b/acinclude.m4  Sun Jul 28 13:26:13 2019 +0200
@@ -660,11 +660,7 @@
 
 #if ! defined (__cplusplus)
 unsigned long
-lshift_com (rp, up, n, cnt)
-  unsigned long *rp;
-  unsigned long *up;
-  long n;
-  unsigned cnt;
+lshift_com (unsigned long *rp, unsigned long *up, long n, unsigned cnt)
 {
   unsigned long retval, high_limb, low_limb;
   unsigned tnc;
@@ -711,11 +707,7 @@
 #if ! defined (__cplusplus)
 #include 
 void
-lshift_com (rp, up, n, cnt)
-  unsigned long *rp;
-  unsigned long *up;
-  long n;
-  unsigned cnt;
+lshift_com (unsigned long *rp, unsigned long *up, long n, unsigned cnt)
 {
   unsigned long high_limb, low_limb;
   unsigned tnc;
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: not really a bug but somewhat odd : checking compiler /usr/local/bin/gcc8 ... no, mpn_lshift_com

[Vincent Lefevre]

On 2019-07-28 06:12:06 -0400, Dennis Clarke wrote:
> configure:6813: ./a.out || ./b.out || ./a.exe || ./a_out.exe || ./conftest
> Abort trap (core dumped)

I don't know in your case, but I fear that this program is buggy.

[...]
> void
> lshift_com (rp, up, n, cnt)
>   unsigned long *rp;
>   unsigned long *up;
>   long n;
>   unsigned cnt;

It uses the old pre-ANSI K function definition, and AFAIK, in
this case, there is no notion of prototype, i.e. it is expected
that the caller passes compatible types as the compiler will not
be able to do type conversion. Note that the 4th parameter, cnt,
is of type unsigned int.

> {
>   unsigned long high_limb, low_limb;
>   unsigned tnc;
>   long i;
>   up += n;
>   rp += n;
>   tnc = 8 * sizeof (unsigned long) - cnt;
>   low_limb = *--up;
>   high_limb = low_limb << cnt;
>   for (i = n - 1; i != 0; i--)
> {
>   low_limb = *--up;
>   *--rp = ~(high_limb | (low_limb >> tnc));
>   high_limb = low_limb << cnt;
> }
>   *--rp = ~high_limb;
> }
> int
> main ()
> {
>   unsigned long *r, *r2;
>   unsigned long a[88 + 1];
>   long i;
>   for (i = 0; i < 88 + 1; i++)
> a[i] = ~0L;
>   r = malloc (1 * sizeof (unsigned long));
>   r2 = r;
>   for (i = 0; i < 528; i += 23)
> {
>   lshift_com (r2, a,
>   i / (8 * sizeof (unsigned long)) + 1,
>   i % (8 * sizeof (unsigned long)));

Here the 4th argument is of type >= long since i is of type long.
With calling via registers, this may not be an issue (here, the
value would be correct), but if the data are passed on the stack,
this will probably not work.

>   r2 += 88 + 1;
> }
>   if (r[2048] != 0 || r[2049] != 0 || r[2050] != 0 || r[2051] != 0 ||
>   r[2052] != 0 || r[2053] != 0 || r[2054] != 0)
> abort ();
>   free (r);
>   return 0;
> }
[...]

If you want an example about K function definition issues,
consider

foo (a)
{
}

main ()
{
  foo (1, 2);
  return 0;
}

With GCC, this builds without any error.

-- 
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_set_si loses long long value on Windows

[Vincent Lefevre]

On 2019-07-24 11:29:42 +0200, Torbjorn Granlund wrote:
> The problem with MPFR's approach is that the library API depends on the
> compiler.

Yes, but note that this is also the case with GMP, for the
formatted output functions. :)

> (We could solve that issue by rejecting pre-C99 compilers.  GMP
> currently is C90. Your intmax_t is also C99.)

For GMP and formatted output functions:

 h short
 hhchar
 j intmax_t or uintmax_t
 l long or wchar_t
 lllong long
 L long double
 q quad_t or u_quad_t
 t ptrdiff_t
 z size_t

quad_t isn't even in C99.

-- 
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_set_si loses long long value on Windows

[Vincent Lefevre]

On 2019-07-24 11:11:46 +0200, Torbjorn Granlund wrote:
> Dim XY  writes:
>   This 'signed long int' type has different sizes of linux (8 bytes) and
>   windows 64bit (4 bytes) platforms
>   (https://en.cppreference.com/w/cpp/language/types)
> 
>   Maybe it is better to use 'long long' type which always has the size
>   of 8 bytes on any platform?
> 
> You're essentially lobbying for an incompatible change in GMP by
> making a spurious GMP bug report.

GNU MPFR has mpfr_set_sj and mpfr_set_uj (when intmax_t is available)
in addition to mpfr_set_si and mpfr_set_ui.

Perhaps it could be nice for GMP to also have mpz_set_sj and
mpz_set_uj in addition to mpz_set_si and mpz_set_ui.

-- 
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: GMP test fails with -flto

[Vincent Lefevre]

On 2019-07-03 10:45:24 +0200, Richard Biener wrote:
> On Wed, Jul 3, 2019 at 9:49 AM Vincent Lefevre  wrote:
> > Here, after loop enrolling, the compiler could see that the arguments
> > are known and generate a fixed puts(). This kind of optimization must
> > not be done with a structure declared as volatile. But I think that
> > data in the structure could be rearranged (what matters is that when
> > run, the program will still do memory accesses and the behavior will
> > be the same); that's rather unlikely, though.
> 
> Could happen though but making the structure object volatile might help
> (the compiler could still see you don't use threads and it's regular data
> and nothing can happen and thus ignore even that...).

C99 says: "An object that has volatile-qualified type may be modified
in ways unknown to the implementation or have other unknown side
effects. Therefore any expression referring to such an object shall
be evaluated strictly according to the rules of the abstract machine,
as described in 5.1.2.3."

No need to use threads. A debugger is sufficient to modify a volatile
object (this is a way "unknown to the implementation").

Note that since there are no other side effects when reading volatile
data here (standard, readable memory), a read is required to be
generated only if the value (which is unknown, as it could have been
modified in a way unknown to the implementation) can affect the output
(which the printf does here).

> The only way to avoid it would be to do sth like
> 
>for (i = 0; i < 8; i++)
>  if (argv[1][2*i])
>foo.before[i] = foo.after[i] = ((char *))[i] = argv[1][2*i+1];
> 
> thus conditionally(! otherwise the compiler might optimize away the
> initializer...) overwrite it from program input.

I don't understand what you want to do here.

> There's also the possibility of the compiler altering the structure
> layout...

Yes. But I think that a copy of the structure and reading the copy
should be sufficient. And all types (at least those related to the
structure) should be volatile-qualified.

-- 
Vincent Lefèvre  - 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: GMP test fails with -flto

[Vincent Lefevre]

On 2019-07-01 16:59:06 +0200, Marc Glisse wrote:
> On Mon, 1 Jul 2019, Vincent Lefevre wrote:
> > I suggest another solution:
> > 
> > First try like now. If the format is unknown, check whether the
> > object file contains the string ".gnu.lto" (which should mean
> > that GCC was used with LTO), and in this case, try again with
> > "-fno-lto" as the patch was doing.
> 
> We also have problems with clang's version of LTO. IIRC using emscripten to
> compile GMP has a similar issue.

With clang 7 and above, "ThinLTO" appears in the object file.

-- 
Vincent Lefèvre  - 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: GMP test fails with -flto

[Vincent Lefevre]

On 2019-07-01 16:36:23 +0200, Torbjorn Granlund wrote:
> Vincent Lefevre  writes:
> 
>   I suggest another solution:
> 
>   First try like now. If the format is unknown, check whether the
>   object file contains the string ".gnu.lto" (which should mean
>   that GCC was used with LTO), and in this case, try again with
>   "-fno-lto" as the patch was doing.
> 
> That might work, but it is a bit more complex that ideally.  I believe
> some grep commands do not cope well with binaries.

Alternatively or additionally, use strings + grep (strings is part
of POSIX and first appeared in Issue 4; however it is not listed
in the GNU Coding Standards).

Otherwise "od -b" with awk, possibly in the same awk script as the
detection itself.

> I have forgotten why lto hurts the GMP_C_DOUBLE_FORMAT test.  (That's
> the problematic test, right?)

Yes, with LTO, the object file does not contain the structure as is.
Thus the detection from "od -b conftest.$OBJEXT" does not work.

-- 
Vincent Lefèvre  - 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: GMP test fails with -flto

[Vincent Lefevre]

On 2019-07-01 13:44:04 +0200, Marc Glisse wrote:
> On Mon, 1 Jul 2019, Martin Liška wrote:
> 
> > On 6/24/19 8:57 PM, Marc Glisse wrote:
> > > On Mon, 24 Jun 2019, Martin Liška wrote:
> > > 
> > > > Using -flto one can see a test failure:
> > > 
> > > This is well known, see the archives for details. It is a combination of 
> > > 2 issues:
> > > - (thin) LTO prevents configure from guessing the floating point format
> > > - a bug in the generic GMP code (fixed in master IIRC)
> > > 
> > 
> > Hi.
> > 
> > I've got a patch for the wrong configure of floating point format.
> 
> That's going to break every non-gcc compiler, isn't it?

I suggest another solution:

First try like now. If the format is unknown, check whether the
object file contains the string ".gnu.lto" (which should mean
that GCC was used with LTO), and in this case, try again with
"-fno-lto" as the patch was doing.

-- 
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: failure with Clang's memory sanitizer: use-of-uninitialized-value

[Vincent Lefevre]

On 2019-03-29 06:20:31 +0100, Niels Möller wrote:
> A bit unobvious what MPN_COPY expands to, but possibly some assembly
> that the clang analyzer can't reason about?

I've just looked at the Clang documentation, and it says:

  MemorySanitizer requires that all program code is instrumented. This
  also includes any libraries that the program depends on, even libc.
  Failing to achieve this may result in false reports. For the same
  reason you may need to replace all inline assembly code that writes
  to memory with a pure C/C++ code.

So, indeed, one should recompile GMP with Clang and without asm code.
(BTW, if one needs to also recompile libc, this seems rather
impracticable.)

-- 
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: not really a bug .. is there a way to set the host type in the Makefile.am ?

[Vincent Lefevre]

On 2019-02-18 22:24:35 -0500, Dennis Clarke wrote:
> On 2/18/19 8:25 PM, Vincent Lefevre wrote:
> > On 2019-02-18 16:44:48 -0500, Dennis Clarke wrote:
> >>
> >> This may seem like a strange question but I am running into many
> >> problems while trying to build gcc 8.2.0 for a RISC-V target. With
> >> a cross compiler toolset I am easily able to create output ELF files
> >> for the rv64gc architecture and so that is not a problem. However that
> >> is only possible ( thus far ) when building gmp separately. The gcc code
> >> requires that I extract the gmp/mpfr/mpc sources inside the gcc sources
> >> tree and then build/bootstrap gcc which in turns rebuilds gmp all over
> >> again.  Regardless if it is pre-installed elsewhere or not.
> > [...]
> > 
> > Isn't this a question for the gcc-help mailing-list?
> > 
> 
> Well yes, it is. However given that the problem occurs within the gmp
> and mpfr source builds I felt it can not hurt to ask here.  Given that
> no one seems to know what to do really.

It seems more likely to be an issue with the gcc build scripts.
I don't think that GMP and MPFR can or should do anything.

-- 
Vincent Lefèvre  - 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: compilation fails with CompCert-3.4 on Linux x86-64; patch proposed

[Vincent Lefevre]

On 2019-01-25 10:38:10 +0100, Niels Möller wrote:
> Vincent Lefevre  writes:
> > The code given by the autoconf manual is:
[...]
> >   # elif !defined HAVE_ALLOCA
> >   #  ifdef  __cplusplus
> >   extern "C"
> >   #  endif
> >   void *alloca (size_t);
> >   # endif
> >   #endif
> 
> The last case, declaring alloca, is that expecting that a replacement
> alloca.c is used as a fallback? As far as I see, we don't do that in
> gmp.

I don't understand this last case. It might also be a bug.
This is what I posted:

  http://lists.gnu.org/archive/html/bug-autoconf/2019-01/msg9.html

-- 
Vincent Lefèvre  - 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: compilation fails with CompCert-3.4 on Linux x86-64; patch proposed

[Vincent Lefevre]

On 2019-01-24 15:57:13 +0100, DAVID MONNIAUX wrote:
> > I don't think this is correct, as alloca() may be available even
> > though HAVE_ALLOCA is not defined (e.g. with MinGW).
> But why would you declare alloca() as a function even though you're
> not going to use it (as far as I understand you don't use it if
> HAVE_ALLOCA is not set)?!

This is the case where alloca() is defined only as a macro.
With your first patch:

#if HAVE_ALLOCA
...
#endif

with no #else case. Thus platforms that need a "#define alloca ..."
may miss the definition in the case HAVE_ALLOCA is not defined (the
autoconf manual is not clear about its definition).

I agree that

  # elif !defined HAVE_ALLOCA
  #  ifdef  __cplusplus
  extern "C"
  #  endif
  void *alloca (size_t);
  # endif

looks strange. I would have thought that the first line should
have been

  # elif defined HAVE_ALLOCA

Or there is another reason, but the code looks wrong. I've just
reported a bug for clarification.

-- 
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: compilation fails with CompCert-3.4 on Linux x86-64; patch proposed

[Vincent Lefevre]

On 2019-01-24 08:46:12 +0100, DAVID MONNIAUX wrote:
> Fix: do not declare alloca() unless HAVE_ALLOCA is set (CompCert
> does not have alloca()). Patch below:

I don't think this is correct, as alloca() may be available even
though HAVE_ALLOCA is not defined (e.g. with MinGW).

The code given by the autoconf manual is:

  #ifdef STDC_HEADERS
  # include 
  # include 
  #else
  # ifdef HAVE_STDLIB_H
  #  include 
  # endif
  #endif
  #ifdef HAVE_ALLOCA_H
  # include 
  #elif !defined alloca
  # ifdef __GNUC__
  #  define alloca __builtin_alloca
  # elif defined _AIX
  #  define alloca __alloca
  # elif defined _MSC_VER
  #  include 
  #  define alloca _alloca
  # elif !defined HAVE_ALLOCA
  #  ifdef  __cplusplus
  extern "C"
  #  endif
  void *alloca (size_t);
  # endif
  #endif

(not tested with GMP and/or MPFR, but I had added a FIXME in MPFR
to consider switching to it).

-- 
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: Asserts considered harmful (or GMP spills its sensitive information)

[Vincent Lefevre]

On 2018-12-31 14:38:17 -0500, Jeffrey Walton wrote:
> On Mon, Dec 31, 2018 at 2:16 PM Vincent Lefevre  wrote:
> >
> > On 2018-12-31 13:03:27 -0500, Jeffrey Walton wrote:
> > > The GMP library uses asserts to crash a program at runtime when
> > > presented with data it did not expect. The library also ignores user
> > > requests to remove asserts using Posix's -DNDEBUG. Posix asserts are a
> > > deugging aide intended for developement, and using them in production
> > > software ranges from questionable to insecure.
> >
> > That's much better than letting the program run erratically, with
> > possible memory corruption and/or sensitive information leakage
> > to unauthorized users. You'd better fix bugs in your program.
> 
> To play devil's advocate for this particular example, GMP could have
> validated the parameters and refused to process the data. That is, the
> function could have returned failure and avoided the potential
> information leak.

Unfortunately, this is not always possible, while keeping the original
interface. Moreover, changing the interface can make the library
slower, which could be an issue for GMP (the goal is to be as fast
as possible, just like the C language was designed, where contrary
to other languages, there's the notion of undefined behavior). If you
don't like that, you can write a wrapper library that will sanitize
all the inputs and implement error processing (e.g. where the return
value contains an error code and the result, if any), and call this
library instead of GMP.

Said that, developers who forget to check whether they correctly
follow the API conditions also forget to check failures. Thus this
ends up with a similar issue (a crash).

Moreover, some asserts may come from the detection of an inconsistent
state. In this case, it is better to abort. Otherwise letting the
program continue may have worse consequences.

-- 
Vincent Lefèvre  - 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: Asserts considered harmful (or GMP spills its sensitive information)

[Vincent Lefevre]

On 2019-01-01 11:22:56 +0100, Joerg Arndt wrote:
> * Vincent Lefevre  [Jan 01. 2019 11:11]:
> > [...]
> > > 
> > > Second, the SIGABRT terminates the process and can write a core file.
> > 
> > That's the default behavior, but you can trap SIGABRT if you want.
> 
> From man 3 abort:
>   If the SIGABRT signal is ignored, or caught by a handler that
>   returns, the abort() function will still terminate the process.  It
>   does this by restoring the default disposition for SIGABRT and then
>   raising the signal for a second time.

Yes, that's why if you want to avoid process termination, you need
to write a handler that does not return (as said in the man page).
This is rather intuitive: if the handler returns, resuming the
program at the same point makes no sense because in general, the
memory state at this point is not valid.

-- 
Vincent Lefèvre  - 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: Bug in gmp/mpfr/mpc, never ending ctan computation

[Vincent Lefevre]

On 2018-11-19 15:26:00 +0100, Richard Biener wrote:
> On Mon, 19 Nov 2018, Vincent Lefevre wrote:
> > AFAIK, GCC already changes the exponent range to the binary64 one
> > (the lack of subnormals is not an issue, because in case of underflow,
> > GCC ignores the computations done with MPFR).
> 
> GCC does ignore results in case of overflow or underflow but it
> doesn't currently limit mpfrs exponent range.  Or rather most
> languages don't - I do see mpfr_set_e{min,max} calls being
> done in the Fortran frontend only, but only temporarily and
> seemingly only to call mpfr_subnormalize.

Thanks for the clarification. FYI, mpfr_subnormalize was added
for gfortran.

> > But for its internal computations, I assume that mpc extends the
> > exponent range (if it didn't you would have the same kind of problem,
> > but much more often). Here it seems that the issue is that the maximum
> > supported exponent range is not large enough for the chosen algorithm
> > (which may not be the right one for this kind of input).
> 
> It happens that limiting the range makes the CPOW computation fast.

Yes, because for some functions, underflow or overflow can be detected
before the actual computation.

-- 
Vincent Lefèvre  - 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: Bug in gmp/mpfr/mpc, never ending ctan computation

[Vincent Lefevre]

On 2018-11-19 12:49:12 +0100, Richard Biener wrote:
> I see.  So I guess one issue might be that mpfr numbers have a
> precision (mantissa bits?) but no restriction on the exponent?

MPFR has a bounded (user configurable) exponent range, with underflow
and overflow exceptions for out-of-range results, like in IEEE 754.

-- 
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

detection of FILE definition under Cygwin

[Vincent Lefevre]

It seems that FILE definition is not detected under Cygwin. Sorry
for the lack of information, but in case someone can test or give
more information...

For the background, see

  
https://stackoverflow.com/questions/49880944/cygwins-gcc-compiler-warning-from-mpfr-library

and my answer

  https://stackoverflow.com/a/49896200/3782797

-- 
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: note: documentation bug

[Vincent Lefevre]

Hi,

On 2018-02-25 20:37:49 +0100, Stéphane Bosio wrote:
> the following can be read:
> 
>-- Function: void mpz_rrandomb (mpz_t ROP, gmp_randstate_t STATE,
>   mp_bitcnt_t N)
>  Generate a random integer with long strings of zeros and ones in
>  the binary representation.  Useful for testing functions and
>  algorithms, since this kind of random numbers have proven to be
>  more likely to trigger corner-case bugs.  The random number
>will be
>  in the range 2^N-1 to 2^N-1, inclusive.
> 
> I'm pretty sure the intended range isn't 2^N-1 to 2^N-1, which is a single
> number, not a range and not random at all.

This is a rendering bug in the info format.
The first one should be 2^(N-1).

-- 
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: [MPFR] Mac OS X power pc issue with C99

[Vincent Lefevre]

Hi,

On 2018-02-19 09:19:02 -0700, arn...@skeeve.com wrote:
> Hi. On this system:
> 
> $ uname -a
> Darwin arnold-robbinss-powerbook-g4-12.local 9.8.0 Darwin Kernel Version 
> 9.8.0: Wed Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power 
> Macintosh
> 
> $ gcc --version
> powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)
> Copyright (C) 2005 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> GMP 4.3.1 and MPFR 3.1.0
> 
> If I configure gawk with c99, I get link problems. This can be seen
> in gawk-4.1.4. (I disabled MPFR for gawk 4.2.0 for this system). I get
> 
> $ make
> make 'CFLAGS=-g -O2 -DNDEBUG' 'LDFLAGS=' all-recursive
> Making all in .
> c99  -g -O2 -DNDEBUG   -o gawk array.o awkgram.o builtin.o cint_array.o 
> command.o debug.o dfa.o eval.o ext.o field.o floatcomp.o gawkapi.o gawkmisc.o 
> getopt.o getopt1.o int_array.o io.o main.o mpfr.o msg.o node.o profile.o 
> random.o re.o regex.o replace.o str_array.o symbol.o version.o  
> -L/usr/local/lib -lintl -liconv -lc  -lreadline -lmpfr -lgmp 
> ld: duplicate symbol ___gmpz_abs in awkgram.o and array.o
> collect2: ld returned 1 exit status
> make[2]: *** [gawk] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> 
> Any ideas or suggestions? Will newer versions of GMP / MPFR still work
> on this platform?

This seems neither a GMP bug, nor a MPFR bug, because the problem
is between awkgram.o and array.o. They seem to define a symbol name
reserved for GMP (I assume that if gmp.h did this, this would have
been detected at least by MPFR tests).

Moreover, GMP 4.3.1 and MPFR 3.1.0 are old...

> Please include me on all replies as I am not subscribed to these two
> lists.

-- 
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: parallel make bug in tune/ directory

[Vincent Lefevre]

On 2018-02-15 13:07:32 +0100, Torbjorn Granlund wrote:
> Vincent Lefevre <vinc...@vinc17.net> writes:
> 
>   The user always has the right to use the -j option if he wants to.
> 
> Thanks for clarifying that, Vincent!
> 
> Unfortunately, the result will be a build error in the tune subdir.  But
> I assume the GMP developers have The Right to release GMP without
> parallel developer subdir builds?  :-)
>   
>   '.NOTPARALLEL'
>   
>If '.NOTPARALLEL' is mentioned as a target, then this invocation of
>'make' will be run serially, even if the '-j' option is given.  Any
>recursively invoked 'make' command will still run recipes in
>parallel (unless its makefile also contains this target).  Any
>prerequisites on this target are ignored.
> 
> Patch?

Attached. Before this change, "make tune" was failing (I don't have
to specify -j explicitly since this is the default config on my
machines, hence the particular importance of .NOTPARALLEL). After
this change, "make tune" runs sequentially and I don't get a build
failure for tune ("make tune" failed with an abort just because
"speed_measure() could not get 4 results within 1.0%" I assume).

-- 
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)
diff -r 164971d5c8d0 tune/Makefile.am
--- a/tune/Makefile.am  Sat Feb 10 18:05:32 2018 +0100
+++ b/tune/Makefile.am  Thu Feb 15 13:22:08 2018 +0100
@@ -180,3 +180,5 @@
echo "#include \"mpz/fac_ui.c\"" >>fac_ui.c
 
 include ../mpn/Makeasm.am
+
+.NOTPARALLEL:
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Configure fails on 32-bit platform

[Vincent Lefevre]

On 2018-02-12 12:52:49 +0100, Torbjorn Granlund wrote:
> It is less common that people set CC/CFLAGS to bad values (or at least
> we don't hear about that very often).  I don't think we should try to
> accomodate that since it would result in lots of fragile complexity.
> (If you don't agree, please see the logic for "ABI" -> (CFLAGS,mpn_path)
> selection.)

The problem here may be somewhere else. On an x86_64 machine, with
just "gcc", the processor is regarded as an x86_64: the __x86_64
macro is defined. But if one uses -m32, then the processor is
regarded as a 32-bit x86: __x86_64 is no longer defined; __i386 and
__i686 are defined instead.

The selection of the ABI seems to be based on $host in configure.ac:

case $host in
  [...]
  X86_PATTERN | X86_64_PATTERN)
abilist="32"
[...]
case $host in
  X86_64_PATTERN)
cclist_64="gcc cc"
[...]
abilist="64 x32 32"
[...]

So, in case of 32-bit x86 mode in the compiler, shouldn't $host be
seen as matching X86_PATTERN instead of X86_64_PATTERN?

Otherwise, since abilist="64 x32 32", for X86_64_PATTERN, shouldn't 32
be tried if 64 and x32 do not work (i.e. as if the user set ABI=32)?
There's a "for abi in $abilist; do" loop. So I'm wondering whether it
does all the necessary tests it could do. Here, it appears to decide
too early that ABI=64 is working.

-- 
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: Configure fails on 32-bit platform

[Vincent Lefevre]

On 2018-02-12 10:31:23 +0100, Torbjorn Granlund wrote:
> Vincent Lefevre <vinc...@vinc17.net> writes:
> 
>   As written above, this is for C compilers. But GMP also has assembler
>   code. So, you need to provide an option that will affect the assembler
>   code. This is what ABI is for.
>   
>   That said, perhaps GMP might be improved to detect the ABI by a
>   simple parsing of $CFLAGS when provided by the user (in case values
>   like -m32 or -m64 are standard). The reason is that the user could
>   have a generic CFLAGS for various software, while AFAIK, ABI is
>   specific to GMP.
> 
> That would be nice but unfortunately is not going to work.
> 
> We use "ABI" in a somewhat non-standard way.  It mainly refers to the
> limb size.  The same exact compiler flags might be correct for several
> choices of "ABI".

So, if I understand correctly, this means that if the user chooses
to set -m32 in CFLAGS, he might have to try different ABI values
before finding one that works (because -m32 does not necessarily
imply 32-bit limbs). This is not nice.

-- 
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: Configure fails on 32-bit platform

[Vincent Lefevre]

On 2018-02-11 19:21:33 -0500, Jeffrey Walton wrote:
> That's not true. In fact, Stallman specifically tells the project to
> adds the flags it needs. Below is from Section 7.2.3 of
> https://www.gnu.org/prep/standards/standards.html. This would fix the
> ARM compile problem, too:
> 
> 
> 
> If there are C compiler options that must be used for proper
> compilation of certain files, do not include them in CFLAGS. Users
> expect to be able to specify CFLAGS freely themselves. Instead,
> arrange to pass the necessary options to the C compiler independently
> of CFLAGS, by writing them explicitly in the compilation commands or
> by defining an implicit rule, like this:
[...]

As written above, this is for C compilers. But GMP also has assembler
code. So, you need to provide an option that will affect the assembler
code. This is what ABI is for.

That said, perhaps GMP might be improved to detect the ABI by a
simple parsing of $CFLAGS when provided by the user (in case values
like -m32 or -m64 are standard). The reason is that the user could
have a generic CFLAGS for various software, while AFAIK, ABI is
specific to GMP.

-- 
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: repl-vsnprintf.c:396:0: error: ISO C forbids an empty translation unit

[Vincent Lefevre]

On 2018-02-11 10:40:55 +0100, Torbjorn Granlund wrote:
> Dennis Clarke  writes:
> 
>   repl-vsnprintf.c:396:0: error: ISO C forbids an empty translation unit
> 
> Our nightly builds get a few of those too, as warnings.  I've decided I
> can live with those as no platform seems to actually dislike the
> resulting object files.

Or you can just add a dummy typedef to ensure that the translation unit
is not empty.

-- 
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

printf/repl-vsnprintf.c bug (was: GMP|MPIR|MPFR assertions)

[Vincent Lefevre]

[Cc to gmp-bugs]

On 2018-01-18 23:14:12 +1100, sisyph...@optusnet.com.au wrote:
> Just had a reply on the mingw64 mailing list.
> Apparently, the test programs are not crashing - abort() is being called
> following an assertion failure.
> And this calls for a "break abort" prior to "run" being called.
> 
> See attached backtrace for tfprintf.exe. (I could supply equivalent for the
> other 2 failing test programs - but I think they're essentially the same.)

printf/repl-vsnprintf.c seems buggy for floating-point specifiers
(EeGgFf). Replace "break" by "goto next" (2 occurrences)?

-- 
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: GMP 6.1.2 t-count_zeros failure on ARM with assertions

[Vincent Lefevre]

On 2018-01-17 17:23:02 +0100, Marc Glisse wrote:
> Indeed, it doesn't make sense to have both the assertion and
> COUNT_LEADING_ZEROS_0. Would it work to remove the assertion instead?

Yes, this works too (assuming that 0 will always be converted to +0).

-- 
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: GMP 6.1.2 t-count_zeros failure on ARM with assertions

[Vincent Lefevre]

On 2017-12-27 17:15:43 +0100, Niels Möller wrote:
> Vincent Lefevre <vinc...@vinc17.net> writes:
> 
> >> 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.
> 
> Thanks for testing. Pushed now.

This is not sufficient. I get a failure for 32-bit x86 with MinGW.
This one is incorrect too:

#else /* ! pentiummmx || LONGLONG_STANDALONE */
/* The following should be a fixed 14 cycles or so.  Some scheduling
   opportunities should be available between the float load/store too.  This
   sort of code is used in gcc 3 for __builtin_ffs (with "n&-n") and is
   apparently suggested by the Intel optimizing manual (don't know exactly
   where).  gcc 2.95 or up will be best for this, so the "double" is
   correctly aligned on the stack.  */
#define count_leading_zeros(c,n)\
  do {  \
union { \
  doubled;  \
  unsigned  a[2];   \
} __u;  \
ASSERT ((n) != 0);  \
__u.d = (UWtype) (n);   \
(c) = 0x3FF + 31 - (__u.a[1] >> 20);\
  } while (0)
#define COUNT_LEADING_ZEROS_0   (0x3FF + 31)
#endif /* pentiummx */

There's also a typo in the latest comment. Patch attached.

-- 
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)
diff -r bd031c4d736b longlong.h
--- a/longlong.hWed Jan 17 05:34:55 2018 +0100
+++ b/longlong.hWed Jan 17 17:05:06 2018 +0100
@@ -965,8 +965,7 @@
 __u.d = (UWtype) (n);  \
 (c) = 0x3FF + 31 - (__u.a[1] >> 20);   \
   } while (0)
-#define COUNT_LEADING_ZEROS_0   (0x3FF + 31)
-#endif /* pentiummx */
+#endif /* pentiummmx */
 
 #else /* ! pentium */
 
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs