Valgrind reports use of uninitialised value for __gmpz_powm_sec on i686 host

2023-08-28 Thread Trevor Spiteri
Valgrind is reporting the use of uninitialised value(s) in 
__gmpz_powm_sec for i686 host, though I found no similar issue for 
x86_64 host. This issue started in 6.3.0, and was not there for 6.2.1.


Please find the details below.

Best regards,
Trevor Spiteri


GMP version 6.3.0 (unpatched) configured on an x86_64 build system using:

gmp-6.3.0/configure --host i686


Configure prints:

configure: summary of build options:

  Version:   GNU MP 6.3.0
  Host type: i686-pc-none
  ABI:   32
  Install prefix:/usr/local
  Compiler:  gcc
  Static libraries:  yes
  Shared libraries:  no


Contents of a.c:

#include 
int main(void)
{
  mpz_t base, exp, mod, ret;
  int error_code;
  mpz_init_set_ui(base, 7);
  mpz_init_set_ui(exp, 4);
  mpz_init_set_ui(mod, 13);
  mpz_init(ret);
  mpz_powm_sec(ret, base, exp, mod);
  if (mpz_cmp_ui(ret, 9))
error_code = 1;
  else
error_code = 0;
  mpz_clear(ret);
  mpz_clear(mod);
  mpz_clear(exp);
  mpz_clear(base);
  return error_code;
}


Compiled using:

gcc -m32 a.c -I . -L .libs -lgmp


Executing ./a.out returns no error. But "valgrind ./a.out" reports:

==207620== Memcheck, a memory error detector
==207620== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==207620== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==207620== Command: ./a.out
==207620==
==207620== Conditional jump or move depends on uninitialised value(s)
==207620==at 0x8049489: __gmpz_powm_sec (in 
/home/trevor/scratch/val_gmp/a.out)
==207620==by 0x804923D: main (in /home/trevor/scratch/val_gmp/a.out)
==207620==
==207620== Conditional jump or move depends on uninitialised value(s)
==207620==at 0x8049309: __gmpz_cmp_ui (in 
/home/trevor/scratch/val_gmp/a.out)
==207620==by 0x804924E: main (in /home/trevor/scratch/val_gmp/a.out)
==207620==
==207620== Conditional jump or move depends on uninitialised value(s)
==207620==at 0x8049254: main (in /home/trevor/scratch/val_gmp/a.out)
==207620==
==207620==
==207620== HEAP SUMMARY:
==207620== in use at exit: 0 bytes in 0 blocks
==207620==   total heap usage: 4 allocs, 4 frees, 16 bytes allocated
==207620==
==207620== All heap blocks were freed -- no leaks are possible
==207620==
==207620== Use --track-origins=yes to see where uninitialised values come from
==207620== For lists of detected and suppressed errors, rerun with: -s
==207620== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)



Additional information:

Distribution:
Fedora 38

gcc-v:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap 
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared 
--enable-threads=posix --enable-checking=release --enable-multilib 
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions 
--enable-gnu-unique-object --enable-linker-build-id 
--with-gcc-major-version-only --enable-libstdcxx-backtrace 
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu 
--enable-plugin --enable-initfini-array 
--with-isl=/builddir/build/BUILD/gcc-13.2.1-20230728/obj-x86_64-redhat-linux/isl-install
 --enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-offload-defaulted --enable-gnu-indirect-function --enable-cet 
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux 
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20230728 (Red Hat 13.2.1-1) (GCC)


uname -a:

Linux hawat 6.4.11-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Aug 16 17:42:12 
UTC 2023 x86_64 GNU/Linux


gmp-6.3.0/config.guess:

nehalem-pc-linux-gnu


sh gmp-6.3.0/configfsf.guess:

x86_64-pc-linux-gnu


valgrind --version:

valgrind-3.21.0

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs


Re: Outdated libtool creates trouble on macOS

2023-08-28 Thread Marc Glisse

On Sun, 27 Aug 2023, Torbjörn Granlund wrote:


We have been using the default shell.gmplib.org autotools tools for a
week now, for generating the public snapshots and the nightbuild
snapshots.  Things look good.


Do you think we could increase AC_PREREQ to 2.70 (or even 2.71), which 
would allow a couple more cleanups? I don't think we want to support users 
rerunning autoconf with an older version than the one we use to generate 
the tarballs.


--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs


Re: Outdated libtool creates trouble on macOS

2023-08-28 Thread Torbjörn Granlund
Marc Glisse  writes:

  Do you think we could increase AC_PREREQ to 2.70 (or even 2.71), which
  would allow a couple more cleanups? I don't think we want to support
  users rerunning autoconf with an older version than the one we use to
  generate the tarballs.

Sure.  Being compatible with older versions than what we use seems quite
unnecessary.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs


Re: Valgrind reports use of uninitialised value for __gmpz_powm_sec on i686 host

2023-08-28 Thread Torbjörn Granlund
Trevor Spiteri  writes:

  Valgrind is reporting the use of uninitialised value(s) in
  __gmpz_powm_sec for i686 host, though I found no similar issue for
  x86_64 host. This issue started in 6.3.0, and was not there for 6.2.1.

I tried this, and it looks like a valgrind bug rather than a GMP bug.

I inserted a print of the single-limb result in mpz/powm_sec.c, just
after the call to mpn_powm_sec.  The result is 9 as expected, but
valgrind claims that 9 is not initialised.

Quite extraordinary that the result can be correct while valgrind says
nobody generated any result.

I also wrote well-defined garbage to that same location before the
mpn_sec_powm call.  That proves that the 9 just didn't happen to be
there, but that mpn_sec_powm wrote it there.  Still valgrind thinks the
location is not well-defined.

Possibly, valgrind tracks something which it thinks is not well-defined,
but that the error becomes delayed?

(I cannot reproduce this for a 64-bit build.)


-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs