[MPFR] assertion failed: size_s1 >= m

josepguardia commented 2 years ago

After installing mpfr it doesn't seem to work well.

This simple program:


#include <iostream>
#include <gmp.h>
#include <mpfr.h>

int main() {
    std::cout << "hello " << mpfr_get_version() << std::endl;
    mpfr_prec_t p = 100;
    mpfr_t r;
    mpfr_init2(r, p);
    mpfr_set_str(r, "0.00000000001", 10, MPFR_RNDD);
    mpfr_printf("Value is: %.25Rf\n", r);
    mpfr_clear(r);
    return 0;
}

I build it:

vcpkg.exe install mpfr:x64-windows

"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat"

"C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe" test_1.cpp gmp.lib mpfr.lib /EHsc /I c:\local\vcpkg\installed\x64-windows\include /MT /link /LIBPATH:"c:/local/vcpkg/installed/x64-windows/lib" /out:test_1.exe /subsystem:console

set PATH=c:/local/vcpkg/installed/x64-windows/bin

test_1.exe

And I get:

hello 4.1.0
.././../src/mpfr-4-8955d4bc66.clean/src/get_str.c:157: MPFR assertion failed: size_s1 >= m

But using Debug libraries it works well...

"C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe" test_1.cpp gmpd.lib mpfr.lib /EHsc /I c:\local\vcpkg\installed\x64-windows\include /MT /DEBUG /link /LIBPATH:"c:/local/vcpkg/installed/x64-windows/debug/lib" /out:test_1d.exe /subsystem:console

set PATH=c:/local/vcpkg/installed/x64-windows/debug/bin
test_1d.exe

I also asked to mpfr distribution group... but it seems more related to vcpkg to me. It works well in linux and macos.

https://sympa.inria.fr/sympa/arc/mpfr/2021-12/

Do you know what is happening?

Thanks!

JackBoosY commented 2 years ago

I confirmed size_s1 is 0:

size_s1 = mpn_get_str (str1, b, r + i0, n - i0);

There are 1 errors and 1 warnings:

1>f:\vcpkg\installed\x64-windows\include\gmp.h(1795): warning C4244: 'return': conversion from 'mp_limb_t' to 'unsigned long', possible loss of data
1>f:\vcpkg\installed\x64-windows\include\gmp.h(2240): error C4146: unary minus operator applied to unsigned type, result still unsigned

JackBoosY commented 2 years ago

After some debugging, the different between debug and release is mpn_lshift(a, 0 + 2, 2, 1) returned different values 18446744073618895986 (debug) and 13107199999806695700 (release) in src/getstr.c line 2800.

I have less knowledge with mpfr and gmp, can you send this to the upstream?

Thanks.

zimmermann6 commented 2 years ago

with mpfr 4.1.0 under x86_64 Linux, if I add the following lines around the mpn_lshift command at line 2800:

              gmp_printf ("nx1=%lu n=%lu result+nx1=%Nd\n", nx1, n, result + nx1, n);
              mp_limb_t ret;
              ret = mpn_lshift (a, result + nx1, n , 1);
              gmp_printf ("ret=%lu a=%Nd\n", ret, a, n);

I get:

nx1=2 n=2 result+nx1=120892581961462917470617599999954672185
ret=0 a=241785163922925834941235199999909344370

The value a has two limbs, the least significant is 18446744073618895986 and the most significant is 13107199999999999999.

josepguardia commented 2 years ago

As it is commented here:

https://sympa.inria.fr/sympa/arc/mpfr/2021-12/msg00007.html

Maybe the solution could be changing the dependency of MPFR from GMP to MPIR.

JackBoosY commented 2 years ago

@josepguardia That's avoid this issue, not fix this issue. The question is why the debug version is correct but release version has this issue.

vinc17fr commented 2 years ago

The question is why the debug version is correct but release version has this issue.

Maybe an optimization bug in the compiler (this would not be the first time that an optimization bug affects MPFR). You could try to rebuild with and without optimizations, and compare.

github-actions[bot] commented 1 month ago

This is an automated message. Per our repo policy, stale issues get closed if there has been no activity in the past 180 days. The issue will be automatically closed in 14 days. If you wish to keep this issue open, please add a new comment.

zimmermann6 commented 1 month ago

does the bug still appear with newer versions of vcpkg?