Re: A unary minus operator was applied to an unsigned type - conversion from 64 Bit to 32 Bit

[Vincent Lefevre]

On 2024-09-04 12:31:08 +0200, marco.bodr...@tutanota.com wrote:
> But an "Error" is worst than a "Warning" isn't it?

Note that in my initial reply in the MPFR mailing-list, I only saw
the warning (the messages were only in German and also obfuscated
by HTML markup and characters encoded as HTML entities).

> And the ERROR "A unary minus operator was applied to an unsigned type" is 
> triggered by the following lines:
> mp_limb_t
> mpn_neg (mp_ptr __gmp_rp, mp_srcptr __gmp_up, mp_size_t __gmp_n)
> {
> [...]
>   *__gmp_rp = (- *__gmp_up) & GMP_NUMB_MASK;
> [...]
> }
> 
> To negate an mpn (an unsigned type), the relevant mp_limb_t (an unsigned 
> type) is negated.
> How can we write this more clearly than this way?

Concerning this one, I agree that there is nothing wrong in the
GMP code and probably no better way to write it, as the goal is
precisely to negate an unsigned integer modulo 2^width, which is
exactly what the unary minus operator is for when applied on an
unsigned integer (similar to the other arithmetic operators).
There is nothing hidden by the code.

-- 
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: A unary minus operator was applied to an unsigned type - conversion from 64 Bit to 32 Bit

[Vincent Lefevre]

On 2024-08-25 10:15:22 +0200, Marc Glisse wrote:
> This one is Microsoft deciding to reject perfectly valid, meaningful,
> standard conformant code for "security" reasons because they target newbies
> who are unlikely to write a bigint type themselves. You can disable the
> Security Development Lifecycle with /sdl- (or look for it in the menus of
> visual studio) or you can try something more specific like /wd4146
> (untested).

Well, GCC also has warnings, such as -Wconversion (though it is
currently broken), for suspicious code, which could be used together
with -Werror.

> In both cases, it is possible to obfuscate the code in ways that make the
> error/warning disappear on some versions of some compilers, and many
> projects do that, but historically that hasn't been GMP's policy.

I think that the end user should be able to use such warnings for
*his own code*. So, if possible, public header files should be written
in such a way to avoid warnings provided by well-known compilers.

I don't think that just adding a cast to avoid an implicit conversion
can be regarded as obfuscating the code. On the contrary, IMHO,
an implicit conversion that may change the value is some kind of
obfuscation.

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

GMP 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 (&got, 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 (&got, 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: mini-gmp mpz_powm incorrect result

[Vincent Lefevre]

On 2022-08-30 08:45:34 +0200, Niels Möller wrote:
> Paul Zimmermann  writes:
> 
> > $ diff -u mini-gmp.c.orig mini-gmp.c
> > --- mini-gmp.c.orig 2022-08-29 10:28:20.700995412 +0200
> > +++ mini-gmp.c  2022-08-29 10:27:36.112191428 +0200
> > @@ -3060,6 +3060,7 @@
> >if (en == 0)
> >  {
> >mpz_set_ui (r, 1);
> > +  mpz_tdiv_r (r, r, m);
> >return;
> >  }
> 
> Should solve the problem, but maybe a bit overkill to call mpz_tdiv_r. Perhaps
> 
>mpz_set_ui (r, mpz_cmpabs_ui (m, 1) != 0);
> 
> or even (mn == 0 check just above this code rules out |m| < 1)
> 
>mpz_set_ui (r, mpz_cmpabs_ui (m, 1));

Concerning this second solution, the GMP manual says:

 -- Function: int mpz_cmpabs_ui (const mpz_t OP1, unsigned long int OP2)
 Compare the absolute values of OP1 and OP2.  Return a positive
 value if abs(OP1) > abs(OP2), zero if abs(OP1) = abs(OP2), or a
 negative value if abs(OP1) < abs(OP2).

So if the mpz_cmpabs_ui implementation is changed so that it can
return a value larger than 1, you need to make sure to remember to
update the code.

-- 
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: Compilation fails when inttypes.h without uint_least32_t definition present but stdint.h with definition present

[Vincent Lefevre]

On 2021-05-24 10:31:05 +0200, Marc Glisse wrote:
> There was a suggestion in the other thread to change GMP-6.* to include
> stdint.h if present, independently of inttypes.h (move the code outside of
> #else). That does look like a simple idea, I don't expect too many platforms
> to have conflicts between the 2 headers.

FYI, this is what I did for MPFR in 2010:

r7083 | vlefevre | 2010-08-16 11:21:21 +0200 (Mon, 16 Aug 2010) | 12 lines

Avoid a compilation failure on OSF/1 (Tru64) 5.1 due to non-C99
conformance though  is available. In various source
files and m4 files, use the following form only:

#if HAVE_INTTYPES_H
# include 
#endif
#if HAVE_STDINT_H
# include 
#endif

Updated README.dev to mention this form.

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

Hi,

On 2020-11-09 06:29:47 +0100, Marco Bodrato wrote:
> That file will be changed in the next release. Please look if the applied
> patch fits your needs.
> https://gmplib.org/repo/gmp-6.2/rev/ad3ca09cfa38

/* This is similar to POSIX strcasecmp except that we don't do the comparison
   with unsigned char.  We avoid strcasecmp for C standard conformance.  */
static int
str_casecmp (const char *s1, const char *s2)
{
  size_t i;
  for (i = 0;; i++)
{
  int c1 = s1[i];
  int c2 = s2[i];
  if (c1 == 0 || tolower (c1) != tolower (c2))
return c1 - c2;
}
}

Is there a reason not to do the comparison with unsigned char?

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

-- 
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-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), "=&r,&r" (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), "=&r,&r" (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 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), "=&r,&r" (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), "=&r,&r" (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.

-- 
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), "=&r,&r" (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), "=&r,&r" (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), "=&r,&r" (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), "=&r,&r" (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

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

[Vincent Lefevre]

On 2019-09-04 17:39:14 +0200, Torbjorn Granlund wrote:
> The compilation command omits $EXEEXT and so does the od command.  Thet
> looks consistent to me, so it should work.  Why does that not work on
> DOS?  Will the compiler naughtily append .exe anyway?

Yes, it does.

-- 
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 >&AC_FD_CC 2>&1"
+gmp_compile="$CC $CFLAGS $CPPFLAGS conftest.c -o conftest$EXEEXT >&AC_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" >&AC_FD_CC
-od -b conftest >&AC_FD_CC
+echo "cannot match anything, conftest$EXEEXT contains" >&AC_FD_CC
+od -b conftest$EXEEXT >&AC_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 07:40:38 -0400, Dennis Clarke wrote:
> On 7/28/19 7:32 AM, Vincent Lefevre wrote:
> > 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.
> > 
> 
> Thank you for that but I suspect the problem lay entirely elsewhere in
> an unexpected place :

I don't see how you can deduce that.

The error occurs at:

> #2  0x0008101cf41c in abort () from /lib/libc.so.7
> #3  0x1cb4 in main () at foo.c:51

Thus in the program

> hydra$ cat foo.c
> 
> /* The following is mis-compiled by Intel ia-64 icc version 1.8 under
> "icc -O3",  After several calls, the function writes partial garbage to
> the result vector.  Perhaps relates to the chk.a.nc insn.  This code
> needs
> to be run to show the problem, but that's fine, the offending cc is a
> native-only compiler so we don't have to worry about cross
> compiling.  */
> 
> #if ! defined (__cplusplus)
> #include 
> 
> void lshift_com (rp, up, n, cnt)
>   unsigned long *rp;
>   unsigned long *up;
>   long n;
>   unsigned cnt;
> {
>   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)));
>   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 ();

It is this abort that has been called, i.e. the memory does not contain
what is expected. An incorrect type sent to lshift_com due to missing
prototype (as with K&R function definition) could perfectly yield this
kind of problem.

>   free (r);
>   return 0;
> }
> 
> #else
> 
> int main () {
>   return 0;
> }
> 
> #endif
> 
> hydra$
> 
> 
> That compiles and runs fine on FreeBSD x86_64 with gcc 8.3.0 however on
>  the ppc64 boxen :
[...]
> (gdb) run
> Starting program:
> /opt/bw/build/gmp-6.1.2_FreeBSD_13.0-CURRENT_r350103_ppc64.001/foo
> 
> Program received signal SIGABRT, Aborted.
> 0x00081026b898 in .__sys_thr_kill () from /lib/libc.so.7
> (gdb) bt
> #0  0x00081026b898 in .__sys_thr_kill () from /lib/libc.so.7
> #1  0x00081026af3c in .__raise () from /lib/libc.so.7
> #2  0x0008101cf41c in abort () from /lib/libc.so.7
> #3  0x1cb4 in main () at foo.c:51
> (gdb) quit
> A debugging session is active.
> 
> Inferior 1 [process 3361] will be killed.
> 
> Quit anyway? (y or n) y
> hydra$
> 
> Well looks to be in libc.so.7 here.   :-(

libc.so.7 behaves as expected: an abort has been called in foo.c,
thus the library aborts the program.

-- 
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: 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&R 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&R 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 13:45:22 +0200, Torbjorn Granlund wrote:
> I think we should require C99 for GMP 7.

Unfortunately, that's not enough. One practical issue is the MS-Windows
environment (again) and the Microsoft runtime. We have the following in
MPFR's INSTALL file (note the mention of GMP):

3 - To avoid using the Microsoft runtime (which might not be conform to ISO C),
you can use the MinGW runtime package (which is an integral part of MinGW).
For example, with MinGW versions 3.15 and later you can get an
ISO-compliant printf() if you compile your application with either
'-ansi', '-posix' or '-D__USE_MINGW_ANSI_STDIO'. In order to have the
MPFR formatted output functions based on ISO-compliant printf(), you
need to compile GMP (not MPFR) with CC="gcc -D__USE_MINGW_ANSI_STDIO"
(since the standard printf modifiers %e, %Ld and %td are passed to GMP).
Not doing so may result in failures of some of the printf-related tests.
For instance, the following error on some Windows machine has been
reported:

  https://sympa.inria.fr/sympa/arc/mpfr/2016-02/msg00053.html

  Error in mpfr_vsprintf (s, "%e", ...);
  expected: "-1.25e+000"
  got:  "-1.25e+00"
  FAIL tsprintf.exe (exit status: 1)

The cause is that here the C functions vsnprintf and vsprintf used
internally in GMP do not produce the same output:

  https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00045.html
  https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00051.html
  https://sympa.inria.fr/sympa/arc/mpfr/2016-03/msg00053.html

Building MPFR with -D__USE_MINGW_ANSI_STDIO is currently useless except
for some error messages in the test suite.

-- 
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 *)&foo.x)[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-02 12:41:15 +0200, Torbjorn Granlund wrote:
> Richard Biener  writes:
> 
>   On Mon, Jul 1, 2019 at 11:13 PM Torbjörn Granlund  wrote:
>   >
>   > Vincent Lefevre  writes:
>   >
>   >   Yes, with LTO, the object file does not contain the structure as is.
>   >   Thus the detection from "od -b conftest.$OBJEXT" does not work.
>   >
>   > That could be solved by generating a final executable, right?
>   >
>   Yes.

I would say that this may not work due to optimization (even if the
structure is in a different file than main(), as LTO could optimize
anyway). If the structure is declared as volatile, I think that
this will always prevent related optimization, but I'm not sure.
Generating a library should always work, IMHO.

> Does the patch below make sense?
> 
> The main funcion is needed as we create an executable, its references to
> foo are needed, else LTO will remove foo altogether.
> 
> *** /tmp/extdiff.MsIr0g/gmp-main.3300fbb5d615/acinclude.m4Mon Jun 17 
> 00:11:50 2019
> --- /home/tege/prec/gmp-main/acinclude.m4 Tue Jul  2 12:37:53 2019
> ***
> *** 3307,3313 
> -123456789.0,
> { '\376', '\334', '\272', '\230', '\166', '\124', '\062', '\020' },
> ! };]
>   EOF
> ! gmp_compile="$CC $CFLAGS $CPPFLAGS -c conftest.c >&AC_FD_CC 2>&1"
>   if AC_TRY_EVAL(gmp_compile); then
>   cat >conftest.awk <<\EOF
> --- 3307,3320 
> -123456789.0,
> { '\376', '\334', '\272', '\230', '\166', '\124', '\062', '\020' },
> ! };
> ! int main(){
> !   int i;
> !   for (i = 0; i < 8; i++) {
> ! printf ("%d %d %f\n", foo.before[i] + foo.after[i], foo.x);
> !   }

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.

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

failure with Clang's memory sanitizer: use-of-uninitialized-value

[Vincent Lefevre]

On my Debian/unstable x86_64 machine (with GMP 6.1.2):

#include 

int main (void)
{
  mpz_t z;

  mpz_init (z);
  mpz_set_ui (z, 1);
  mpz_dump (z);
  mpz_clear (z);

  return 0;
}

compiled with: clang-7 -fsanitize=memory -o tst tst.c -lgmp

gives the following error:

cventin:~> ./tst
Uninitialized bytes in __interceptor_puts at offset 1 inside [0x70100010, 2)
==17647==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7fbf03e6fe6a in __gmpz_dump 
(/usr/lib/x86_64-linux-gnu/libgmp.so.10+0x18e6a)
#1 0x49518a in main (/home/vlefevre/tst+0x49518a)
#2 0x7fbf03aeb09a in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
#3 0x41e2b9 in _start (/home/vlefevre/tst+0x41e2b9)

SUMMARY: MemorySanitizer: use-of-uninitialized-value 
(/usr/lib/x86_64-linux-gnu/libgmp.so.10+0x18e6a) in __gmpz_dump
Exiting
zsh: exit 77./tst

-- 
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] missing va_end() in some IO functions (gmp 6.1.2)

[Vincent Lefevre]

On 2019-03-14 12:38:13 +0100, Torbjorn Granlund wrote:
> Is stdarg.h va_end non-empty anywhere?

Yes, with GCC and Clang, for instance. It is defined as:

#define va_end(v)   __builtin_va_end(v)

gcc/builtins.c contains:

static rtx
expand_builtin_va_end (tree exp)
{
  tree valist = CALL_EXPR_ARG (exp, 0);

  /* Evaluate for side effects, if needed.  I hate macros that don't
 do that.  */
  if (TREE_SIDE_EFFECTS (valist))
expand_expr (valist, const0_rtx, VOIDmode, EXPAND_NORMAL);

  return const0_rtx;
}

So, if I understand correctly, it does nothing except than taking
care of side effects. However, since the C standard explicitly says
that va_end is a macro, I'm not sure that having arguments with
side effects is allowed. What GCC does is probably safer than
doing nothing (without any drawback), though.

This means that with GMP, __builtin_va_end(v) would expand to nothing.

BTW, I've just fixed a bug in tcc, which did

#define va_end(ap)

instead of

#define va_end(ap) ((void)0)

This matters when writing, e.g.: (va_end(ap));

-- 
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] missing va_end() in some IO functions (gmp 6.1.2)

[Vincent Lefevre]

On 2019-03-14 12:38:13 +0100, Torbjorn Granlund wrote:
> My bad, part of Jakub's patch is needed for standards compliance.
> 
> In gmp-impl.h, we have this:
> 
>   /* va_copy is standard in C99, and gcc provides __va_copy when in strict C89
>  mode.  Falling back to a memcpy will give maximum portability, since it
>  works no matter whether va_list is a pointer, struct or array.  */
>   #if ! defined (va_copy) && defined (__va_copy)
>   #define va_copy(dst,src)  __va_copy(dst,src)
>   #endif
>   #if ! defined (va_copy)
>   #define va_copy(dst,src) \
> do { memcpy (&(dst), &(src), sizeof (va_list)); } while (0)
>   #endif
> 
> We still support ISO C90 (alias ANSI C89) so we cannot just scrap that
> code.  That means that we mustn't call va_end when memcpy was used by
> means of the code above.

But will va_arg necessarily work when va_copy is just a memcpy
(at least in the case where va_end is *not* empty)? This seems
optimistic.

-- 
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] missing va_end() in some IO functions (gmp 6.1.2)

[Vincent Lefevre]

On 2019-03-13 17:05:02 +0100, Niels Möller wrote:
> Vincent Lefevre  writes:
> 
> > Moreover, the va_end(3) man page says:
> >
> >   On  some  systems,  va_end  contains  a  closing  '}' matching a '{' in
> >   va_start, so that both macros must occur in the same function, and in a
> >   way that allows this.
> 
> Curious. Which man page, and which systems?

The va_end(3) man page (which is actually the stdarg(3) man page)
under Linux. See:

  http://man7.org/linux/man-pages/man3/stdarg.3.html

> On such systems, va_copy would similarly have to be a macro with an
> unmatched '{' in the expansion, right? Sounds more than a bit awful.

Yes. But apparently this is just history. So, I suppose that this
rule on braces could be safely ignored nowadays. I've reported a
bug to have this paragraph removed from the man page:

  https://bugzilla.kernel.org/show_bug.cgi?id=202907

-- 
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] missing va_end() in some IO functions (gmp 6.1.2)

[Vincent Lefevre]

On 2019-03-13 13:48:17 +0100, Torbjorn Granlund wrote:
> Jakub Martisko  writes:
> 
>   I believe there are some missing va_end() calls in some of the IO
>   functions of GMP 6.1.2. See attached patch for details.
> 
> Are you sure that's how stdarg works?
> 
> I see no problems with GMP's current code.  I believe your patch is
> incorrect in several ways.

I won't comment on the patch here, but GMP's current code appears
to be incorrect. For instance, printf/doprnt.c uses va_copy several
times, but I can see no matching va_end.

As described in the va_copy(3) man page:

Each invocation of va_copy() must be matched by a corresponding
invocation of va_end() in the same function.

-- 
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] missing va_end() in some IO functions (gmp 6.1.2)

[Vincent Lefevre]

On 2019-03-13 12:16:29 +0100, Jakub Martisko wrote:
> I believe there are some missing va_end() calls in some of the IO
> functions of GMP 6.1.2. See attached patch for details.

A few notes about your patch...

--- a/printf/snprntffuns.c
+++ b/printf/snprntffuns.c
@@ -85,6 +85,7 @@ gmp_snprintf_format (struct gmp_snprintf_t *d, const char 
*fmt,
   d->buf += step;

   if (ret != avail-1)
+va_end(ap);
 return ret;

This one is incorrect since the "return ret;" will no longer be
in the "if" branch.

Moreover, the va_end(3) man page says:

  On  some  systems,  va_end  contains  a  closing  '}' matching a '{' in
  va_start, so that both macros must occur in the same function, and in a
  way that allows this.

Thus even

   if (ret != avail-1)
 {
   va_end(ap);
   return ret;
 }

would not work on such systems.

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

[Vincent Lefevre]

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?

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