Bug #130736 for Math-BigInt: to_ieee754-mbf.t failing in 1.999817

Fri Oct 18 07:48:57 2019 shay [...] cpan.org - Ticket created

Subject:

to_ieee754-mbf.t failing in 1.999817

I recently updated blead to 1.999817 but somehow failed to run tests before pushing, and I've now noticed that one is failing. Verbose output attached. We have a blead release on Sun 20th. It would be great if this could be fixed by then. If not then I will just revert the update.

Subject:

output.txt

D:\Dev\Git\perl\t>.\perl harness -v ../cpan/Math-BigInt/t/to_ieee754-mbf.t ../cpan/Math-BigInt/t/to_ieee754-mbf.t .. 1..60 # # Computing test data for k = 16 ... # # # smallest positive subnormal number (k = 16) # ok 1 # # largest subnormal number (k = 16) # ok 2 # # smallest positive normal number (k = 16) # ok 3 # # largest normal number (k = 16) # ok 4 # # largest number less than one (k = 16) # ok 5 # # smallest number larger than one (k = 16) # ok 6 # # second smallest number larger than one (k = 16) # ok 7 # # one (k = 16) # ok 8 # # minus one (k = 16) # ok 9 # # two (k = 16) # ok 10 # # minus two (k = 16) # ok 11 # # positive zero (k = 16) # ok 12 # # positive infinity (k = 16) # ok 13 # # negative infinity (k = 16) # ok 14 # # NaN (encoding used by Perl on Cygwin) (k = 16) # ok 15 # # Computing test data for k = 32 ... # # # smallest positive subnormal number (k = 32) # ok 16 # # largest subnormal number (k = 32) # ok 17 # # smallest positive normal number (k = 32) # ok 18 # # largest normal number (k = 32) # ok 19 # # largest number less than one (k = 32) # ok 20 # # smallest number larger than one (k = 32) # ok 21 # # second smallest number larger than one (k = 32) # ok 22 # # one (k = 32) # ok 23 # # minus one (k = 32) # ok 24 # # two (k = 32) # ok 25 # # minus two (k = 32) # ok 26 # # positive zero (k = 32) # ok 27 # # positive infinity (k = 32) # ok 28 # # negative infinity (k = 32) # ok 29 # # NaN (encoding used by Perl on Cygwin) (k = 32) # ok 30 # # Computing test data for k = 64 ... # # # smallest positive subnormal number (k = 64) # ok 31 # # largest subnormal number (k = 64) # ok 32 # # smallest positive normal number (k = 64) # ok 33 # # largest normal number (k = 64) # ok 34 # # largest number less than one (k = 64) # ok 35 # # smallest number larger than one (k = 64) # ok 36 # # second smallest number larger than one (k = 64) # ok 37 # # one (k = 64) # ok 38 # # minus one (k = 64) # ok 39 # # two (k = 64) # ok 40 # # minus two (k = 64) # ok 41 # # positive zero (k = 64) # ok 42 # # positive infinity (k = 64) # ok 43 # # negative infinity (k = 64) # ok 44 # # NaN (encoding used by Perl on Cygwin) (k = 64) # ok 45 # # Computing test data for k = 128 ... # # # smallest positive subnormal number (k = 128) # Can't take log of 0 at ../../lib/Math/BigFloat.pm line 4474. # Looks like your test exited with 34 just after 45. Dubious, test returned 34 (wstat 8704, 0x2200) Failed 15/60 subtests Test Summary Report ------------------- ../cpan/Math-BigInt/t/to_ieee754-mbf.t (Wstat: 8704 Tests: 45 Failed: 0) Non-zero exit status: 34 Parse errors: Bad plan. You planned 60 tests but ran 45. Files=1, Tests=45, 1 wallclock secs ( 0.00 usr + 0.00 sys = 0.00 CPU) Result: FAIL D:\Dev\Git\perl\t>

Fri Oct 18 09:37:27 2019 peter.john.acklam [...] gmail.com - Correspondence added

This error puzzles me, as the zero case is taken care of before execution gets to this point. Anyway, I doubt I will be able to reproduce this error without more information about the platform and how perl was built. I guess from the prompt that this is some sort of Windows version, but other than that, I have nothing. Could you show me the output from "perl -V"?

Fri Oct 18 09:37:28 2019 The RT System itself - Status changed from 'new' to 'open'

Fri Oct 18 12:00:38 2019 shay [...] cpan.org - Correspondence added

On Fri Oct 18 09:37:27 2019, pjacklam wrote: Show quoted text

> This error puzzles me, as the zero case is taken care of before > execution gets to this point. > > Anyway, I doubt I will be able to reproduce this error without more > information about the platform and how perl was built. I guess from > the prompt that this is some sort of Windows version, but other than > that, I have nothing. Could you show me the output from "perl -V"?

Apologies. I should have included that information, of course. Please find perl -V output attached. This is Visual C++ 2019 (v16.3.4) x64 on Windows 10.

Subject:

perl-V.txt

Summary of my perl5 (revision 5 version 31 subversion 5) configuration: Commit id: 859b78b1a8287681e524286f4e989b01816433ba Platform: osname=MSWin32 osvers=10.0.18362.388 archname=MSWin32-x64-multi-thread uname='' config_args='undef' hint=recommended useposix=true d_sigaction=undef useithreads=define usemultiplicity=define use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='cl' ccflags ='-nologo -GF -W3 -O1 -MD -Zi -DNDEBUG -GL -fp:precise -DWIN32 -D_CONSOLE -DNO_STRICT -DWIN64 -DCONSERVATIVE -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS' optimize='-O1 -MD -Zi -DNDEBUG -GL -fp:precise' cppflags='-DWIN32' ccversion='19.23.28106.4' gccversion='' gccosandvers='' intsize=4 longsize=4 ptrsize=8 doublesize=8 byteorder=12345678 doublekind=3 d_longlong=undef longlongsize=8 d_longdbl=define longdblsize=8 longdblkind=0 ivtype='__int64' ivsize=8 nvtype='double' nvsize=8 Off_t='__int64' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='link' ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -ltcg -libpath:"c:\perl\lib\CORE" -machine:AMD64 -subsystem:console,"5.02"' libpth="C:\Program Files (x86)\Microsoft Visual Studio\2019 16.3\Professional\VC\Tools\MSVC\14.23.28105\\lib\x64" libs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib vcruntime.lib ucrt.lib perllibs=oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib comctl32.lib msvcrt.lib vcruntime.lib ucrt.lib libc=ucrt.lib so=dll useshrplib=true libperl=perl531.lib gnulibc_version='' Dynamic Linking: dlsrc=dl_win32.xs dlext=dll d_dlsymun=undef ccdlflags=' ' cccdlflags=' ' lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -ltcg -libpath:"c:\perl\lib\CORE" -machine:AMD64 -subsystem:console,"5.02"' Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES HAVE_INTERP_INTERN MULTIPLICITY PERLIO_LAYERS PERL_COPY_ON_WRITE PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_MALLOC_WRAP PERL_OP_PARENT PERL_PRESERVE_IVUV USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_PERLIO USE_PERL_ATOF USE_THREAD_SAFE_LOCALE Built under MSWin32 Compiled at Oct 18 2019 10:01:39 @INC: D:/Dev/Git/perl/lib

Sat Oct 19 09:41:28 2019 peter.john.acklam [...] gmail.com - Correspondence added

With the perl you compiled with Visual C++ 2019 (v16.3.4) x64 on Windows 10, could you please execute the following and show me the output. perl -MMath::BigFloat -le "($m, $e) = Math::BigFloat -> new('0.5') -> bpow('16494') -> nparts(); print for $m -> numify(), 0 + $m -> bstr()" You should get two lines displaying the number "6.47517511943802" (or "6.47517511943802511092443895822765" if perl is compiled with quadmath support). So far, I have not been able to reproduce the error. On Cygwin 64 bit I have tried with perl compiled with and without quadmath, with and without threads, and with/without multiplicity (8 combinations in all). On Cygwin 32 bit I have in addition tried with and without 64 bit integers (16 combinations in all). All of this for various versions of perl. I have also tried blead perl. In addition to all of this, I have tried with Strawberry Perl on Windows. None of these give the error you have displayed.

Sat Oct 19 12:47:45 2019 steve.m.hay [...] googlemail.com - Correspondence added

CC:	shay [...] cpan.org
Subject:	Re: [rt.cpan.org #130736] to_ieee754-mbf.t failing in 1.999817
Date:	Sat, 19 Oct 2019 17:47:16 +0100
To:	bug-Math-BigInt [...] rt.cpan.org
From:	Steve Hay <steve.m.hay [...] googlemail.com>

On Sat, 19 Oct 2019 at 14:41, Peter John Acklam via RT <bug-Math-BigInt@rt.cpan.org> wrote: Show quoted text

> > <URL: https://rt.cpan.org/Ticket/Display.html?id=130736 > > > With the perl you compiled with Visual C++ 2019 (v16.3.4) x64 on Windows 10, could you please execute the following and show me the output. > > perl -MMath::BigFloat -le "($m, $e) = Math::BigFloat -> new('0.5') -> bpow('16494') -> nparts(); print for $m -> numify(), 0 + $m -> bstr()" > > You should get two lines displaying the number "6.47517511943802" (or "6.47517511943802511092443895822765" if perl is compiled with quadmath support). > > So far, I have not been able to reproduce the error. On Cygwin 64 bit I have tried with perl compiled with and without quadmath, with and without threads, and with/without multiplicity (8 combinations in all). On Cygwin 32 bit I have in addition tried with and without 64 bit integers (16 combinations in all). All of this for various versions of perl. I have also tried blead perl. In addition to all of this, I have tried with Strawberry Perl on Windows. None of these give the error you have displayed.

Only the second line of output is as expected. The first line is 0: D:\Dev\Git\perl>perl -v This is perl 5, version 31, subversion 5 (v5.31.5 (v5.31.4-373-g859b78b1a8)) built for MSWin32-x64-multi-thread Copyright 1987-2019, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using "man perl" or "perldoc perl". If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. D:\Dev\Git\perl>where cl C:\Program Files (x86)\Microsoft Visual Studio\2019 16.3\Professional\VC\Tools\MSVC\14.23.28105\bin\Hostx64\x64\cl.exe D:\Dev\Git\perl>cl Microsoft (R) C/C++ Optimizing Compiler Version 19.23.28106.4 for x64 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] D:\Dev\Git\perl>perl -MMath::BigFloat -le "print $Math::BigFloat::VERSION" 1.999817 D:\Dev\Git\perl>perl -MMath::BigFloat -le "($m, $e) = Math::BigFloat -> new('0.5') -> bpow('16494') -> nparts(); print for $m -> numify(), 0 + $m -> bstr()" 0 6.47517511943802 D:\Dev\Git\perl>

Sat Oct 19 13:40:42 2019 steve.m.hay [...] googlemail.com - Correspondence added

CC:	shay [...] cpan.org
Subject:	Re: [rt.cpan.org #130736] to_ieee754-mbf.t failing in 1.999817
Date:	Sat, 19 Oct 2019 18:42:31 +0100
To:	bug-Math-BigInt [...] rt.cpan.org
From:	Steve Hay <steve.m.hay [...] googlemail.com>

On Sat, 19 Oct 2019 at 17:47, Steve Hay <steve.m.hay@googlemail.com> wrote: Show quoted text

> > On Sat, 19 Oct 2019 at 14:41, Peter John Acklam via RT > <bug-Math-BigInt@rt.cpan.org> wrote:

> > > > <URL: https://rt.cpan.org/Ticket/Display.html?id=130736 > > > > > With the perl you compiled with Visual C++ 2019 (v16.3.4) x64 on Windows 10, could you please execute the following and show me the output. > > > > perl -MMath::BigFloat -le "($m, $e) = Math::BigFloat -> new('0.5') -> bpow('16494') -> nparts(); print for $m -> numify(), 0 + $m -> bstr()" > > > > You should get two lines displaying the number "6.47517511943802" (or "6.47517511943802511092443895822765" if perl is compiled with quadmath support). > > > > So far, I have not been able to reproduce the error. On Cygwin 64 bit I have tried with perl compiled with and without quadmath, with and without threads, and with/without multiplicity (8 combinations in all). On Cygwin 32 bit I have in addition tried with and without 64 bit integers (16 combinations in all). All of this for various versions of perl. I have also tried blead perl. In addition to all of this, I have tried with Strawberry Perl on Windows. None of these give the error you have displayed.

> > Only the second line of output is as expected. The first line is 0: >

I'm wondering if this might be a bug in this version of VC++?... I've just tried with VC++ 2013 and all the tests pass. I'll try 2015 and 2017 and let you know how they fare.

Sat Oct 19 13:49:11 2019 peter.john.acklam [...] gmail.com - Correspondence added

Thank you so much! The problem is in Math::BigFloat->numify() which converts an object $x to a scalar by using 0 + $x -> bsstr(); which converts $x to a string and, by adding zero, lets atof()/atoi() convert the string to a number. In this case, the string is 6475175119438025110924438(...)e-11528 where the (...) represents no less than 11500 omitted digits. The mantissa aka. significand is a 11529 digit integer, which is way beyond what can be represented by a double precision floating point number. I am actually impressed that some systems get this right. Anyway, the fix is to use 0 + $x -> bnstr(); in numify(). I am sure that if you try this, you get the correct result.

Sat Oct 19 15:08:40 2019 shay [...] cpan.org - Correspondence added

On Sat Oct 19 13:49:11 2019, pjacklam wrote: Show quoted text

> Thank you so much! The problem is in Math::BigFloat->numify() which > converts an object $x to a scalar by using > > 0 + $x -> bsstr(); > > which converts $x to a string and, by adding zero, lets atof()/atoi() > convert the string to a number. In this case, the string is > > 6475175119438025110924438(...)e-11528 > > where the (...) represents no less than 11500 omitted digits. The > mantissa aka. significand is a 11529 digit integer, which is way > beyond what can be represented by a double precision floating point > number. I am actually impressed that some systems get this right. > > Anyway, the fix is to use > > 0 + $x -> bnstr(); > > in numify(). I am sure that if you try this, you get the correct > result.

Ok, I will try that later. I've just finished testing with other compilers and I find that VC++ 2015/2017/2019 all fail, whereas VC++ 2010/2013 both work for some reason - but more by luck than anything, it seems!

Sun Oct 20 05:14:01 2019 shay [...] cpan.org - Correspondence added

On Sat Oct 19 15:08:40 2019, SHAY wrote: Show quoted text

> On Sat Oct 19 13:49:11 2019, pjacklam wrote:

> > Thank you so much! The problem is in Math::BigFloat->numify() which > > converts an object $x to a scalar by using > > > > 0 + $x -> bsstr(); > > > > which converts $x to a string and, by adding zero, lets atof()/atoi() > > convert the string to a number. In this case, the string is > > > > 6475175119438025110924438(...)e-11528 > > > > where the (...) represents no less than 11500 omitted digits. The > > mantissa aka. significand is a 11529 digit integer, which is way > > beyond what can be represented by a double precision floating point > > number. I am actually impressed that some systems get this right. > > > > Anyway, the fix is to use > > > > 0 + $x -> bnstr(); > > > > in numify(). I am sure that if you try this, you get the correct > > result.

> > > Ok, I will try that later. I've just finished testing with other > compilers and I find that VC++ 2015/2017/2019 all fail, whereas VC++ > 2010/2013 both work for some reason - but more by luck than anything, > it seems!

Yes, changing 0 + $x -> bsstr() to 0 + $x -> bnstr() in Math::BigFloat::numify() fixes the test failure. Thanks for the fix. I will just patch this locally in blead for today, and upgrade whenever you have a new release out later.

Mon Oct 21 10:28:45 2019 peter.john.acklam [...] gmail.com - Correspondence added

Fixed in 1.999818.

Mon Oct 21 10:28:47 2019 peter.john.acklam [...] gmail.com - Status changed from 'open' to 'resolved'

Mon Oct 21 10:28:47 2019 peter.john.acklam [...] gmail.com - Fixed in 1.999818 added