New test failures (beginning with perl-5.35.10) on -Duselongdouble builds when longdouble is "DoubleDouble"

[sisyphus]

The following addition to ext/Devel-Peek/Peek.t in perl-5.35.10 leads to 2 failed tests on perls built with-Duselongdouble iff the longdouble is "DoubleDouble":

+
+{
+    my $one = 1.0;
+    my $epsilon_p = 1.0;
+    $epsilon_p /= 2 while $one != $one + $epsilon_p / 2;
+    my $epsilon_n = 1.0;
+    $epsilon_n /= 2 while $one != $one - $epsilon_n / 2;
+
+    my $head = 'SV = NV\($ADDR\) at $ADDR
+(?:.+
+)*  ';
+    my $tail = '
+(?:.+
+)*';
+
+    do_test('NV 1.0', $one,
+            $head . 'NV = 1' . $tail);
+    do_test('NV 1.0 + epsilon', $one + $epsilon_p,
+            $head . 'NV = 1\.00000000\d+' . $tail);
+    do_test('NV 1.0 - epsilon', $one - $epsilon_p,
+            $head . 'NV = 0\.99999999\d+' . $tail);
+}
+

Module:
Devel::Peek

Description

Provided above.

Steps to Reproduce

Just build current blead on a system where longdouble is "DoubleDouble" and then run:

./perl -I./lib -T ext/Devel-Peek/t/Peek.t

You'll get output that terminates as follows:

....
ok 139 - DumpProg() has no 'Attempt to free X prematurely' warning
not ok 140 - NV 1.0
#   Failed test 'NV 1.0'
#   at ext/Devel-Peek/t/Peek.t line 109.
#
#                   'SV = PVNV(0x2644bbc0) at 0x2640d2b0
#   REFCNT = 1
#   FLAGS = (IOK,NOK,pIOK,pNOK)
#   IV = 1
#   NV = 1
#   PV = 0
# '
#     doesn't match '(?^ms:\A(?:ALLOCATED at .*?
# )?SV = NV\(0x[[:xdigit:]]+\) at 0x[[:xdigit:]]+
# (?:.+
# )*  NV = 1
# (?:.+
# )*\Z)'
#
# line 1587
ok 141 - NV 1.0 (unchanged by dump)
ok 142 - NV 1.0 + epsilon
ok 143 - NV 1.0 + epsilon (unchanged by dump)
not ok 144 - NV 1.0 - epsilon
#   Failed test 'NV 1.0 - epsilon'
#   at ext/Devel-Peek/t/Peek.t line 109.
#
#                   'SV = NV(0x25bfe850) at 0x26434448
#   REFCNT = 1
#   FLAGS = (NOK,pNOK)
#   NV = 1.00000000000000000000000000000002
# '
#     doesn't match '(?^ms:\A(?:ALLOCATED at .*?
# )?SV = NV\(0x[[:xdigit:]]+\) at 0x[[:xdigit:]]+
# (?:.+
# )*  NV = 0\.99999999\d+
# (?:.+
# )*\Z)'
#
# line 1591
ok 145 - NV 1.0 - epsilon (unchanged by dump)
1..145
# Looks like you failed 2 tests of 145.

Expected behavior

I don't immediately recognize what's being tested here.
(The test script, including the do_test() code, looks quite perlish to me, and I'm not really the "perlish" type.)
If someone likes to come up with a simple demo case of what's failing here, then that's all the better.
Otherwise, I'll put my thinking cap on tomorrow ... and try to work it out.

Perl configuration

# perl -V output goes here

$ ./perl -I./lib -V
Summary of my perl5 (revision 5 version 35 subversion 11) configuration:
Commit id: 2caf827
Platform:
osname=linux
osvers=3.2.0-4-powerpc64
archname=ppc64-linux-ld
uname='linux debian-sis 3.2.0-4-powerpc64 #1 smp debian 3.2.78-1 ppc64 gnulinux '
config_args='-des -Duse64bitall -Dcc=gcc -m64 -Dprefix=/home/sisyphus-sis/perl53511-m64-ld -Duselongdouble -Dusedevel -Uversiononly'
hint=recommended
useposix=true
d_sigaction=define
useithreads=undef
usemultiplicity=undef
use64bitint=define
use64bitall=define
uselongdouble=define
usemymalloc=n
default_inc_excludes_dot=define
Compiler:
cc='gcc -m64'
ccflags ='-std=gnu99 -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
optimize='-O1'
cppflags='-std=gnu99 -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion=''
gccversion='4.6.3'
gccosandvers=''
intsize=4
longsize=8
ptrsize=8
doublesize=8
byteorder=87654321
doublekind=4
d_longlong=define
longlongsize=8
d_longdbl=define
longdblsize=16
longdblkind=6
ivtype='long'
ivsize=8
nvtype='long double'
nvsize=16
Off_t='off_t'
lseeksize=8
alignbytes=16
prototype=define
Linker and Libraries:
ld='gcc -m64'
ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib /lib/powerpc-linux-gnu /lib/../lib /usr/lib/powerpc-linux-gnu /usr/lib/../lib /lib /lib64 /usr/lib64
libs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
libc=libc-2.13.so
so=so
useshrplib=false
libperl=libperl.a
gnulibc_version='2.13'
Dynamic Linking:
dlsrc=dl_dlopen.xs
dlext=so
d_dlsymun=undef
ccdlflags='-Wl,-E'
cccdlflags='-fPIC'
lddlflags='-shared -O1 -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl):
Compile-time options:
HAS_TIMES
PERLIO_LAYERS
PERL_COPY_ON_WRITE
PERL_DONT_CREATE_GVSV
PERL_MALLOC_WRAP
PERL_OP_PARENT
PERL_PRESERVE_IVUV
PERL_USE_DEVEL
USE_64_BIT_ALL
USE_64_BIT_INT
USE_LARGE_FILES
USE_LOCALE
USE_LOCALE_COLLATE
USE_LOCALE_CTYPE
USE_LOCALE_NUMERIC
USE_LOCALE_TIME
USE_LONG_DOUBLE
USE_PERLIO
USE_PERL_ATOF
Built under linux
Compiled at Apr 5 2022 18:11:14
@inc:
./lib
/home/sisyphus-sis/perl53511-m64-ld/lib/site_perl/5.35.11/ppc64-linux-ld
/home/sisyphus-sis/perl53511-m64-ld/lib/site_perl/5.35.11
/home/sisyphus-sis/perl53511-m64-ld/lib/5.35.11/ppc64-linux-ld
/home/sisyphus-sis/perl53511-m64-ld/lib/5.35.11

[jkeenan]

On 4/5/22 08:13, sisyphus wrote: The following addition to ext/Devel-Peek/Peek.t in perl-5.35.10 leads to 2 failed tests on perls built with|-Duselongdouble| iff the longdouble is "DoubleDouble":

Can you clarify what systems/platforms meet this criterion? How would I determine if my machine met the criterion? Can it be simulated on other platforms?

[sisyphus]

Hi Jim,

How would I determine if my machine met the criterion?

One (time-consuming) way would be to build a -Duselongdouble build of perl and then check that perl -V:longdblkind returns a value in the range [5 .. 8] (inclusive).

But, as a quick check, I would just build and run the following C script, using the C toolchain that would be used to build perl:

#include <stdio.h>

int main (void) {
  double d_1 = 1e100;
  double d_2 = 1e-100;

  if((long double)d_1 + (long double)d_2 != (long double)d_1) printf("doubledouble\n");
  else printf("not doubledouble\n");

  return 0;
}

IIRC, the most extreme example of the doubledouble's capability is it's capacity to store the pair of doubles (DBL_MAX, DBL_DENORM_MIN) which is actually a 2098-bit precision value.
OTOH, the value of having this capability is questionable - though the DoubleDouble always provides at least 107 bits of precision, except for values that are either very large or very small.

In my case, the "doubledouble" support is being provided by Debian Wheezy on an old Apple G5 powerpc64 box.
AFAIK, Debian still supports this architecture, and I hope to eventually get around to upgrading my version of Debian on this box.

I would say that support for this non-IEEE data type in Perl is anachronistic - but it's an anachronism I would like to track for as long as possible.
I'd certainly like to remove this current failure ... or, at least, understand it.

There's a reasonable introduction to the DoubleDouble at:
https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Double-double_arithmetic

I guess there are VMs that fake the DoubleDouble architectue ... but I don't know.

Cheers,
Rob

[jkeenan]

The following addition to ext/Devel-Peek/Peek.t in perl-5.35.10 leads to 2 failed tests on perls built with-Duselongdouble iff the longdouble is "DoubleDouble":

+
+{
+    my $one = 1.0;
+    my $epsilon_p = 1.0;
+    $epsilon_p /= 2 while $one != $one + $epsilon_p / 2;
+    my $epsilon_n = 1.0;
+    $epsilon_n /= 2 while $one != $one - $epsilon_n / 2;
+
+    my $head = 'SV = NV\($ADDR\) at $ADDR
+(?:.+
+)*  ';
+    my $tail = '
+(?:.+
+)*';
+
+    do_test('NV 1.0', $one,
+            $head . 'NV = 1' . $tail);
+    do_test('NV 1.0 + epsilon', $one + $epsilon_p,
+            $head . 'NV = 1\.00000000\d+' . $tail);
+    do_test('NV 1.0 - epsilon', $one - $epsilon_p,
+            $head . 'NV = 0\.99999999\d+' . $tail);
+}
+

Those changes were made in this commit:

commit 3bdf66c3d47f0589706b789aaf5b1cc6f02d4e2d
Author:     TAKAI Kousuke <62541129+t-a-k@users.noreply.github.com>
AuthorDate: Tue Mar 8 19:17:35 2022 +0900
Commit:     Yves Orton <demerphq@gmail.com>
CommitDate: Wed Mar 9 03:44:17 2022 +0100

    Add tests for increased NV precision in Devel::Peek::Dump

@demerphq, @t-a-k ... can you take a look?

[demerphq]

On Tue, 5 Apr 2022 at 16:32, James E Keenan ***@***.***> wrote: The following addition to ext/Devel-Peek/Peek.t in perl-5.35.10 leads to 2 failed tests on perls built with-Duselongdouble iff the longdouble is "DoubleDouble": + +{ + my $one = 1.0; + my $epsilon_p = 1.0; + $epsilon_p /= 2 while $one != $one + $epsilon_p / 2; + my $epsilon_n = 1.0; + $epsilon_n /= 2 while $one != $one - $epsilon_n / 2; + + my $head = 'SV = NV\($ADDR\) at $ADDR +(?:.+ +)* '; + my $tail = ' +(?:.+ +)*'; + + do_test('NV 1.0', $one, + $head . 'NV = 1' . $tail); + do_test('NV 1.0 + epsilon', $one + $epsilon_p, + $head . 'NV = 1\.00000000\d+' . $tail); + do_test('NV 1.0 - epsilon', $one - $epsilon_p, + $head . 'NV = 0\.99999999\d+' . $tail); +} + Those changes were made in this commit: commit 3bdf66c Author: TAKAI Kousuke ***@***.***> AuthorDate: Tue Mar 8 19:17:35 2022 +0900 Commit: Yves Orton ***@***.***> CommitDate: Wed Mar 9 03:44:17 2022 +0100 Add tests for increased NV precision in Devel::Peek::Dump @demerphq <https://github.com/demerphq>, @t-a-k <https://github.com/t-a-k> ... can you take a look?

I can look, but all this patch did was make Devel::Peek::Dump output more digits of decimal point. The first error seems to be related to the underlying object being a PVNV instead of a NV. That feels like an artifact. I suspect somewhere the $one is being printed out maybe? The second one is weird, it is a pure NV, but apparently subtracting epsilon from 1 is resulting in a value that is larger than 1. I dont quite get that at first look. Yves

…

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[sisyphus]

Here's a patch which, I think, transforms the intended tests into a form that is suitable for the DoubleDouble build, by special casing that system, yet leaving all other systems untouched.
(All Peek.t tests then pass for me.)

--- Peek.t_orig 2022-04-05 18:02:10.661746628 +1000
+++ Peek.t      2022-04-06 14:57:42.671063881 +1000
@@ -1552,9 +1552,15 @@
 {
     my $one = 1.0;
     my $epsilon_p = 1.0;
-    $epsilon_p /= 2 while $one != $one + $epsilon_p / 2;
     my $epsilon_n = 1.0;
-    $epsilon_n /= 2 while $one != $one - $epsilon_n / 2;
+    if($Config{longdblkind} >= 5 && $Config{longdblkind} <= 8) {
+      $epsilon_p = 2 ** -105;
+      $epsilon_p = 2 ** -105;
+    }
+    else {
+      $epsilon_p /= 2 while $one != $one + $epsilon_p / 2;
+      $epsilon_n /= 2 while $one != $one - $epsilon_n / 2;
+    }

     my $head = 'SV = NV\($ADDR\) at $ADDR
 (?:.+

I've no strong objection to letting this slip by for now, and then provide a PR after 5.36.0 has been released.
The main thing, for me, is that I understand what's happening - which I now do.

In the process of investigating, I found this behaviour which, I believe, will be seen across all platforms with this build of perl.
It also explains the first of the 2 test failures - as $one + 0 was being run (but on DoubleDouble builds only):

$ ./perl -I./lib -MDevel::Peek -le '$x = 1.0; $discard = $x + 0; Dump $x;'
SV = PVNV(0x126f62b0) at 0x1271a218
  REFCNT = 1
  FLAGS = (IOK,NOK,pIOK,pNOK)
  IV = 1
  NV = 1
  PV = 0

It doesn't feel right to see an SV that has only ever been assigned/used in numeric context being classified as PVNV.
However, it's probably of little consequence.
Do we leave this as is ? ... or does this behaviour warrant the creation of a separate issue ?

Cheers,
Rob

[demerphq]

On Wed, 6 Apr 2022 at 07:22, sisyphus ***@***.***> wrote: Here's a patch which, I think, transforms the intended tests into a form that is suitable for the DoubleDouble build, by special casing that system, yet leaving all other systems untouched. (All Peek.t tests then pass for me.)

I was just investigating this too.

--- Peek.t_orig 2022-04-05 18:02:10.661746628 +1000 +++ Peek.t 2022-04-06 14:57:42.671063881 +1000 @@ -1552,9 +1552,15 @@ { my $one = 1.0; my $epsilon_p = 1.0; - $epsilon_p /= 2 while $one != $one + $epsilon_p / 2; my $epsilon_n = 1.0; - $epsilon_n /= 2 while $one != $one - $epsilon_n / 2; + if($Config{longdblkind} >= 5 && $Config{longdblkind} <= 8) { + $epsilon_p = 2 ** -105; + $epsilon_p = 2 ** -105; Shouldn't one of these be $epslion_n?

The test code has a bug where it computes $epsilon_n but does not use it, I think it should be using $epsilon_n and not $epsilon_p.

+ } + else { + $epsilon_p /= 2 while $one != $one + $epsilon_p / 2; + $epsilon_n /= 2 while $one != $one - $epsilon_n / 2; + } my $head = 'SV = NV\($ADDR\) at $ADDR (?:.+ I've no strong objection to letting this slip by for now, and then provide a PR after 5.36.0 has been released.

We should just fix this.

The main thing, for me, is that I understand what's happening - which I now do. In the process of investigating, I found this behaviour which, I believe, will be seen across all platforms with this build of perl. It also explains the first of the 2 test failures - as $one + 0 was being run (but on DoubleDouble builds only): $ ./perl -I./lib -MDevel::Peek -le '$x = 1.0; $discard = $x + 0; Dump $x;' SV = PVNV(0x126f62b0) at 0x1271a218 REFCNT = 1 FLAGS = (IOK,NOK,pIOK,pNOK) IV = 1 NV = 1 PV = 0 It doesn't feel right to see an SV that has only ever been assigned/used in numeric context being classified as PVNV.

Yes, it is weird, and I have not found out why it happens.

However, it's probably of little consequence. Do we leave this as is ? ... or does this behaviour warrant the creation of a separate issue ?

Well in theory it should not matter. In practice we should find out why it happens and fix it. Note that on my system it does not get upgraded. So there is something related to the special type of long-double you have. FWIW, my current patch looks like the following. I am curious if it passes for you or not. I assume not, but it would be nice to know. I suspect we need a combo of your change and my change. diff --git a/ext/Devel-Peek/t/Peek.t b/ext/Devel-Peek/t/Peek.t index 658ac99d98..d8eb401b1d 100644 --- a/ext/Devel-Peek/t/Peek.t +++ b/ext/Devel-Peek/t/Peek.t @@ -1562,13 +1562,15 @@ EODUMP my $tail = ' (?:.+ )*'; - + # Note we guard against the NV being upgraded to a PVNV + # below. Not sure how that could happen, but we have seen + # bug reports where it has. do_test('NV 1.0', $one, - $head . 'NV = 1' . $tail); + $head . '(?:PV)?NV = 1' . $tail); do_test('NV 1.0 + epsilon', $one + $epsilon_p, - $head . 'NV = 1\.00000000\d+' . $tail); - do_test('NV 1.0 - epsilon', $one - $epsilon_p, - $head . 'NV = 0\.99999999\d+' . $tail); + $head . '(?:PV)?NV = 1\.00000000\d+' . $tail); + do_test('NV 1.0 - epsilon', $one - $epsilon_n, + $head . '(?:PV)?NV = 0\.99999999\d+' . $tail); } done_testing();

…

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[demerphq]

On Wed, 6 Apr 2022 at 07:48, demerphq ***@***.***> wrote: On Wed, 6 Apr 2022 at 07:22, sisyphus ***@***.***> wrote: > Here's a patch which, I think, transforms the intended tests into a form > that is suitable for the DoubleDouble build, by special casing that system, > yet leaving all other systems untouched. > (All Peek.t tests then pass for me.) > I was just investigating this too. > --- Peek.t_orig 2022-04-05 18:02:10.661746628 +1000 > +++ Peek.t 2022-04-06 14:57:42.671063881 +1000 > @@ -1552,9 +1552,15 @@ > { > my $one = 1.0; > my $epsilon_p = 1.0; > - $epsilon_p /= 2 while $one != $one + $epsilon_p / 2; > my $epsilon_n = 1.0; > - $epsilon_n /= 2 while $one != $one - $epsilon_n / 2; > + if($Config{longdblkind} >= 5 && $Config{longdblkind} <= 8) { > + $epsilon_p = 2 ** -105; > + $epsilon_p = 2 ** -105; > > Shouldn't one of these be $epslion_n? The test code has a bug where it computes $epsilon_n but does not use it, I think it should be using $epsilon_n and not $epsilon_p. > + } > + else { > + $epsilon_p /= 2 while $one != $one + $epsilon_p / 2; > + $epsilon_n /= 2 while $one != $one - $epsilon_n / 2; > + } > > my $head = 'SV = NV\($ADDR\) at $ADDR > (?:.+ > > I've no strong objection to letting this slip by for now, and then > provide a PR after 5.36.0 has been released. > We should just fix this. > The main thing, for me, is that I understand what's happening - which I > now do. > > In the process of investigating, I found this behaviour which, I believe, > will be seen across all platforms with this build of perl. > It also explains the first of the 2 test failures - as $one + 0 was > being run (but on DoubleDouble builds only): > > $ ./perl -I./lib -MDevel::Peek -le '$x = 1.0; $discard = $x + 0; Dump $x;' > SV = PVNV(0x126f62b0) at 0x1271a218 > REFCNT = 1 > FLAGS = (IOK,NOK,pIOK,pNOK) > IV = 1 > NV = 1 > PV = 0 > > It doesn't feel right to see an SV that has only ever been assigned/used > in numeric context being classified as PVNV. > Yes, it is weird, and I have not found out why it happens.

BTW, that exact command line does produce the same result as you showed, but the tests pass under use-long double without my patch on my system. So the actual test code doesn't seem to do this /for me/. I dont really get it. I will dig deeper tho.

> However, it's probably of little consequence. > Do we leave this as is ? ... or does this behaviour warrant the creation > of a separate issue ? > Well in theory it should not matter. In practice we should find out why it happens and fix it.

I think we should create a new issue for this. Yves

[sisyphus]

BTW, that exact command line does produce the same result as you showed, but the tests pass under use-long double without my patch on my system.

IIUYC, although both our systems react in the same way to $one + 0, it was only the DoubleDouble system that would ever evaluate $one + 0.
Therefore the test failure was limited to the DoubleDouble system.
It was inside the while loops that calculated $epsilon_p and $epsilon_n that the DoubleDouble system would eventually evaluate $one + 0.
Of course, with the patch I provided, the DoubleDouble system never enters those loops, and that test failure is thereby avoided.

And yes - I did intend to assign once to $epsilon_p and once to $epsilon_n, instead of twice to $epsilon_p ;-)
As you (and I) then noticed, $epsilon_n is never used.
I guess it was intended for use in the final test, but $epsilon_p was included instead by mistake.
I think we should fix that mistake ... and also the one that I made ....
The 2 values are generally different from each other - but the same for the DoubleDouble system (2 ** -1074).

More later ... gotta go for a walk before I go nuts (and before it gets dark).

Cheers,
Rob

[sisyphus]

FWIW, my current patch looks like the following. I am curious if it passes for you or not.

The same 2 tests fail.
The second of those failing tests ("NV 1.0 - epsilon") fails for the wrong reason - namely a perl/C printf() bug that displays a value greater than 1, even though perl/C knows it is less than 1.

However, if the bug wasn't there, this test should still fail.
Dump() fills the NV slot with a 33 significant decimal digit representation of the value 1.0 - (2 ** -1074).
A correct "%.33g" representation of that value is 1. The expected result is a value less than 1 ... so it would still fail.

Similarly, the test "NV 1.0 + epsilon" which passes, does so for the wrong reason.
The NV slot is incorrectly filled with a value greater than 1.0 (the same perl/C printf() bug), and is therefore deemed a pass.
But the correct "%.33g" representation of the value 1.0 + (2 ** -1074) is also 1 - and not the expected value of greater than 1.
So a fail would also be the correct result here.

The thing is, that the decimal precisions allocated for the NV slot of non-DoubleDouble NVs is sufficiently large as to ensure that no information is lost.
But a decimal precision of 33 is not large enough to ensure that DoubleDouble information is not lost.
It would need to be raised to 634 to guarantee that information would be preserved for all DoubleDoubles.

With the values used by my patch, all of the tests should pass ... and they do so.

Here's my patch, altered to correctly handle $epsilon_n.

--- Peek.t_orig 2022-04-05 18:02:10.661746628 +1000
+++ Peek.t      2022-04-06 20:56:54.257345663 +1000
@@ -1552,9 +1552,15 @@
 {
     my $one = 1.0;
     my $epsilon_p = 1.0;
-    $epsilon_p /= 2 while $one != $one + $epsilon_p / 2;
     my $epsilon_n = 1.0;
-    $epsilon_n /= 2 while $one != $one - $epsilon_n / 2;
+    if($Config{longdblkind} >= 5 && $Config{longdblkind} <= 8) {
+      $epsilon_p = 2 ** -105;
+      $epsilon_n = 2 ** -105;
+    }
+    else {
+      $epsilon_p /= 2 while $one != $one + $epsilon_p / 2;
+      $epsilon_n /= 2 while $one != $one - $epsilon_n / 2;
+    }

     my $head = 'SV = NV\($ADDR\) at $ADDR
 (?:.+
@@ -1567,7 +1573,7 @@
             $head . 'NV = 1' . $tail);
     do_test('NV 1.0 + epsilon', $one + $epsilon_p,
             $head . 'NV = 1\.00000000\d+' . $tail);
-    do_test('NV 1.0 - epsilon', $one - $epsilon_p,
+    do_test('NV 1.0 - epsilon', $one - $epsilon_n,
             $head . 'NV = 0\.99999999\d+' . $tail);
 }

The value assigned to both $epsilon_p and $epsilon_n for the DoubleDouble has been fudged a bit.
My checks reveal that it should be possible to have $epsilon_p as low as 2 ** -107, and $epsilon_n as low as 2 ** -110.
However, I find that if the power of 2 for either of those variables is less than -105, then at least one test failure occurs.
Again, that is because of the perl/C printf() bug on this DoubleDouble system of mine.

I actually don't mind if we change those 2 occurrences of "-105" in my patch to "-107" and "-110".
That should theoretically work, and the fact that it causes 2 tests to fail on my system is really not a good reason for "fudging".

After I've sent this post off, I'll create a new Issue about the strange "PVNV" setting.

Cheers,
Rob

[demerphq]

On Wed, 6 Apr 2022 at 13:49, sisyphus ***@***.***> wrote: FWIW, my current patch looks like the following. I am curious if it passes for you or not. The same 2 tests fail. The second of those failing tests ("NV 1.0 - epsilon") fails for the wrong reason - namely a perl/C printf() bug that displays a value greater than 1, even though perl/C knows it is less than 1. However, if the bug wasn't there, this test should still fail. Dump() fills the NV slot with a 33 significant decimal digit representation of the value 1.0 - (2 ** -1074). A correct "%.33g" representation of that value is 1. The expected result is a value less than 1 ... so it would still fail. Similarly, the test "NV 1.0 + epsilon" which passes, does so for the wrong reason. The NV slot is incorrectly filled with a value greater than 1.0 (the same perl/C printf() bug), and is therefore deemed a pass.

Shouldn't we create an issue about the printf bug?

But the correct "%.33g" representation of the value 1.0 + (2 ** -1074) is also 1 - and not the expected value of greater than 1. So a fail would also be the correct result here. The thing is, that the decimal precisions allocated for the NV slot of non-DoubleDouble NVs is sufficiently large as to ensure that no information is lost. But a decimal precision of 33 is not large enough to ensure that DoubleDouble information is not lost. It would need to be raised to 634 to guarantee that information would be preserved for all DoubleDoubles. With the values used by my patch, all of the tests should pass ... and they do so.

Thanks, this is very interesting.

Here's my patch, altered to correctly handle $epsilon_n. --- Peek.t_orig 2022-04-05 18:02:10.661746628 +1000 +++ Peek.t 2022-04-06 20:56:54.257345663 +1000 @@ -1552,9 +1552,15 @@ { my $one = 1.0; my $epsilon_p = 1.0; - $epsilon_p /= 2 while $one != $one + $epsilon_p / 2; my $epsilon_n = 1.0; - $epsilon_n /= 2 while $one != $one - $epsilon_n / 2; + if($Config{longdblkind} >= 5 && $Config{longdblkind} <= 8) { + $epsilon_p = 2 ** -105; + $epsilon_n = 2 ** -105; + } + else { + $epsilon_p /= 2 while $one != $one + $epsilon_p / 2; + $epsilon_n /= 2 while $one != $one - $epsilon_n / 2; + } my $head = 'SV = NV\($ADDR\) at $ADDR (?:.+ @@ -1567,7 +1573,7 @@ $head . 'NV = 1' . $tail); do_test('NV 1.0 + epsilon', $one + $epsilon_p, $head . 'NV = 1\.00000000\d+' . $tail); - do_test('NV 1.0 - epsilon', $one - $epsilon_p, + do_test('NV 1.0 - epsilon', $one - $epsilon_n, $head . 'NV = 0\.99999999\d+' . $tail); } So will you create a PR about this? The value assigned to both $epsilon_p and $epsilon_n for the DoubleDouble has been fudged a bit. My checks reveal that it should be possible to have $epsilon_p as low as 2 ** -107, and $epsilon_n as low as 2 ** -110. However, I find that if the power of 2 for either of those variables is less than -105, then at least one test failure occurs. Again, that is because of the perl/C printf() bug on this DoubleDouble system of mine. I actually don't mind if we change those 2 occurrences of "-105" in my patch to "-107" and "-110". That should theoretically work, and the fact that it causes 2 tests to fail on my system is really not a good reason for "fudging". After I've sent this post off, I'll create a new Issue about the strange "PVNV" setting.

OK, I spent the last hour or so digging into that one and I kinda understand it. I have a gdb trace session open to debugging it right now and I can provide it for the ticket once it is created. cheers, Yves

…

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[sisyphus]

Shouldn't we create an issue about the printf bug?

I don't see much chance of this being fixed even if a bug report was made.
The system is Debian Wheezy - which was released in 2013 and EOL'd 4 years ago,
The gcc version is 4.6.3, glibc-2.13.
I would not be surprised if things were much better with more recent software.

The salient point is that this printf() bug is present in the C toolchain - perl is merely mirroring the C issue.

I can use Math::MPFR to provide correct assignment and correct printing of DoubleDoubles, so it's not such an issue for me anyway.

I will do a PR for the isssue I've raised here .... but I'm actually thinking (wrt DoubleDoubles) about well and truly fudging the setting of $epsilon_p and $epsilon_n such that the integer powers of 2 (to which $epsilon_p and $epsilon_n are raised) are minimized as much as possible, but without causing the tests to fail.
That's pretty much what the while{} loops achieved for the non-DoubleDouble NVs ... so why not do it for the DoubleDoubles, too ?

With DoubleDoubles, I'm sort of leaning towards dodging the ingrained bugs, rather than fixing them.

@demerphq, I'll post another (prospective) patch for that tomorrow, and see what you think.

Cheers,
Rob

[t-a-k]

The test code has a bug where it computes $epsilon_n but does not use it, I think it should be using $epsilon_n and not $epsilon_p.

Oh that was my mistake. Thank you for fixing it.

FWIW, my current patch looks like the following. I am curious if it passes
for you or not. I assume not, but it would be nice to know. I suspect we
need a combo of your change and my change.

diff --git a/ext/Devel-Peek/t/Peek.t b/ext/Devel-Peek/t/Peek.t
index 658ac99d98..d8eb401b1d 100644
--- a/ext/Devel-Peek/t/Peek.t
+++ b/ext/Devel-Peek/t/Peek.t
@@ -1562,13 +1562,15 @@ EODUMP
     my $tail = '
 (?:.+
 )*';
-
+    # Note we guard against the NV being upgraded to a PVNV
+    # below. Not sure how that could happen, but we have seen
+    # bug reports where it has.
     do_test('NV 1.0', $one,
-            $head . 'NV = 1' . $tail);
+            $head . '(?:PV)?NV = 1' . $tail);

I think this probably won't work, as this NV = line is intended to match...

SV = NV(0x1504b6c) at 0x14f9bb0
  REFCNT = 1
  FLAGS = (NOK,pNOK)
  NV = 1                                <-- this line

... which never become PVNV = ... even for PVNVs. Instead $head needs to be modified to accept (?:PV)?NV if we shall allow PVNVs.

[haarg]

It has always been the case that various read operations can modify the internals of a value. The simple option seems to be avoiding touching the value before dumping it.

diff --git i/ext/Devel-Peek/t/Peek.t w/ext/Devel-Peek/t/Peek.t
index 658ac99d98..6b22e57842 100644
--- i/ext/Devel-Peek/t/Peek.t
+++ w/ext/Devel-Peek/t/Peek.t
@@ -1550,11 +1550,10 @@ EODUMP
 }
 
 {
-    my $one = 1.0;
     my $epsilon_p = 1.0;
-    $epsilon_p /= 2 while $one != $one + $epsilon_p / 2;
+    $epsilon_p /= 2 while 1.0 != 1.0 + $epsilon_p / 2;
     my $epsilon_n = 1.0;
-    $epsilon_n /= 2 while $one != $one - $epsilon_n / 2;
+    $epsilon_n /= 2 while 1.0 != 1.0 - $epsilon_n / 2;
 
     my $head = 'SV = NV\($ADDR\) at $ADDR
 (?:.+
@@ -1563,11 +1562,11 @@ EODUMP
 (?:.+
 )*';
 
-    do_test('NV 1.0', $one,
+    do_test('NV 1.0', 1.0,
             $head . 'NV = 1' . $tail);
-    do_test('NV 1.0 + epsilon', $one + $epsilon_p,
+    do_test('NV 1.0 + epsilon', 1.0 + $epsilon_p,
             $head . 'NV = 1\.00000000\d+' . $tail);
-    do_test('NV 1.0 - epsilon', $one - $epsilon_p,
+    do_test('NV 1.0 - epsilon', 1.0 - $epsilon_n,
             $head . 'NV = 0\.99999999\d+' . $tail);
 }