[5.19.6] Failing M::BI tests, ppc, -Duselongdouble

[p5pRT]

Migrated from rt.perl.org#120758 (status was 'open')

Searchable as RT120758$

[p5pRT]

From @sisyphus

Reply-To​: sisyphus1@​optusnet.com.au
To​: perlbug@​perl.org
From​: sisyphus1@​optusnet.com.au
Message-Id​: <5.19.6_20663_1386754220@​debian-sis>
Subject​: [5.19.6] Failing M​::BI tests, ppc, -Duselongdouble

This is a bug report for perl from sisyphus1@​optusnet.com.au,
generated with the help of perlbug 1.39 running under perl 5.19.6.

I get the following test failures on a ppc machine running debian wheezy,
where perl is built with -Duselongdouble (106 bit "double-double").

dist/Math-BigInt/t/bare_mbi.t​:

not ok 3467
# Failed test at t/bigintpm.inc line 443.
# got​: '9999999999999999999999999999999e+98'
# expected​: '1e+129'

dist/Math-BigInt/t/bigintpm.t​:

not ok 3461
# Failed test at t/bigintpm.inc line 443.
# got​: '9999999999999999999999999999999e+98'
# expected​: '1e+129'

There's another test script in the same directory that fails with
essentially the same error ... can't recall which script that was.

The failure arises because perl sets the value 1e+129 incorrectly. Unpacking
the long double reveals that perl assigns​:

5ab7151b377c247e5707b80b00474380
instead of the correct​:
5ab7151b377c247e5707b80b00474440

In the correct representation, I think the trailing 6 bits are discarded
and, despite first appearances which suggest that it's a much larger error,
this is an "off-by-three" ulps discrepancy (three ulps too many, IMO) -
probably connected to the bug that led to tickets #120363 and #41202, to
name a couple.

In base 2, correct form is​:
0.1011100010101000110110011011101111100001001000111111000000010111101110000000101100000000010001110100010001E429

whereas, perl assigns​:
0.1011100010101000110110011011101111100001001000111111000000010111101110000000101100000000010001110100001110E429

If perl assigned correctly then these tests would pass, as is.

The same failures on this platform occurred during 'make test' for 5.18.1.

I've seen mention of using POSIX​::strtod to assign to NVs correctly.
Unfortunately, there's no POSIX​::strtold function, so that approach doesn't
help us wrt to long double builds of perl.
I've recently uploaded Math​::NV to CPAN, whose nv() function will assign in
accordance with C's strtold on 'long double' builds of perl.
I mention this in case it's useful here.

---

Flags​:
  category=core
  severity=medium

---

Site configuration information for perl 5.19.6​:

Configured by sisyphus-sis at Wed Dec 4 00​:45​:28 EST 2013.

Summary of my perl5 (revision 5 version 19 subversion 6) configuration​:

  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.51-1 ppc64
gnulinux '
  config_args='-des -Duse64bitint -Duselongdouble -Duse64bitall -Dcc=gcc -m64
-Dprefix=/home/sisyphus-sis/blead-m64 -Dusedevel'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=undef, usemultiplicity=undef
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=define, use64bitall=define, uselongdouble=define
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='gcc -m64', ccflags
='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
  optimize='-O1',
  cppflags='-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
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  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 /lib/powerpc-linux-gnu /lib/../lib
/usr/lib/powerpc-linux-gnu /usr/lib/../lib /lib /usr/lib /lib64 /usr/lib64
  libs=-lnsl -ldl -lm -lcrypt -lutil -lc
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
  libc=, 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'

---

@​INC for perl 5.19.6​:
  /home/sisyphus-sis/blead-m64/lib/perl5/site_perl/5.19.6/ppc64-linux-ld
  /home/sisyphus-sis/blead-m64/lib/perl5/site_perl/5.19.6
  /home/sisyphus-sis/blead-m64/lib/perl5/5.19.6/ppc64-linux-ld
  /home/sisyphus-sis/blead-m64/lib/perl5/5.19.6
  .

---

Environment for perl 5.19.6​:
  HOME=/home/sisyphus-sis
  LANG=en_AU.UTF-8
  LANGUAGE=en_AU​:en
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/home/sisyphus-sis/blead-m64/bin​:/usr/local/bin​:/usr/bin​:/bin​:/usr/local/games​:/usr/games
  PERL_BADLANG (unset)
  SHELL=/bin/bash

[p5pRT]

From @jkeenan

On Wed, 11 Dec 2013 10​:19​:03 GMT, sisyphus wrote​:

Reply-To​: sisyphus1@​optusnet.com.au
To​: perlbug@​perl.org
From​: sisyphus1@​optusnet.com.au
Message-Id​: <5.19.6_20663_1386754220@​debian-sis>
Subject​: [5.19.6] Failing M​::BI tests, ppc, -Duselongdouble

This is a bug report for perl from sisyphus1@​optusnet.com.au,
generated with the help of perlbug 1.39 running under perl 5.19.6.

I get the following test failures on a ppc machine running debian
wheezy,
where perl is built with -Duselongdouble (106 bit "double-double").

dist/Math-BigInt/t/bare_mbi.t​:

not ok 3467
# Failed test at t/bigintpm.inc line 443.
# got​: '9999999999999999999999999999999e+98'
# expected​: '1e+129'

dist/Math-BigInt/t/bigintpm.t​:

not ok 3461
# Failed test at t/bigintpm.inc line 443.
# got​: '9999999999999999999999999999999e+98'
# expected​: '1e+129'

There's another test script in the same directory that fails with
essentially the same error ... can't recall which script that was.

The failure arises because perl sets the value 1e+129 incorrectly.
Unpacking
the long double reveals that perl assigns​:

5ab7151b377c247e5707b80b00474380
instead of the correct​:
5ab7151b377c247e5707b80b00474440

In the correct representation, I think the trailing 6 bits are
discarded
and, despite first appearances which suggest that it's a much larger
error,
this is an "off-by-three" ulps discrepancy (three ulps too many, IMO)
-
probably connected to the bug that led to tickets #120363 and #41202,
to
name a couple.

In base 2, correct form is​:
0.1011100010101000110110011011101111100001001000111111000000010111101110000000101100000000010001110100010001E429

whereas, perl assigns​:
0.1011100010101000110110011011101111100001001000111111000000010111101110000000101100000000010001110100001110E429

If perl assigned correctly then these tests would pass, as is.

The same failures on this platform occurred during 'make test' for
5.18.1.

I've seen mention of using POSIX​::strtod to assign to NVs correctly.
Unfortunately, there's no POSIX​::strtold function, so that approach
doesn't
help us wrt to long double builds of perl.
I've recently uploaded Math​::NV to CPAN, whose nv() function will
assign in
accordance with C's strtold on 'long double' builds of perl.
I mention this in case it's useful here.

1. Does this problem still exist?

2. Am I correct in thinking that it's specific to the ppc64 architecture? (I can't reproduce it on x86_64-linux-ld.)

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @sisyphus

-----Original Message-----
From​: James E Keenan via RT
Sent​: Monday, January 02, 2017 1​:10 PM
To​: sisyphus1@​optusnet.com.au
Subject​: [perl #120758] [5.19.6] Failing M​::BI tests, ppc, -Duselongdouble

On Wed, 11 Dec 2013 10​:19​:03 GMT, sisyphus wrote​:

I get the following test failures on a ppc machine running debian wheezy,
where perl is built with -Duselongdouble (106 bit "double-double").

dist/Math-BigInt/t/bare_mbi.t​:

not ok 3467
# Failed test at t/bigintpm.inc line 443.
# got​: '9999999999999999999999999999999e+98'
# expected​: '1e+129'

dist/Math-BigInt/t/bigintpm.t​:

not ok 3461
# Failed test at t/bigintpm.inc line 443.
# got​: '9999999999999999999999999999999e+98'
# expected​: '1e+129'

There's another test script in the same directory that fails with
essentially the same error ... can't recall which script that was.

The failure arises because perl sets the value 1e+129 incorrectly.
Unpacking the long double reveals that perl assigns​:

5ab7151b377c247e5707b80b00474380
instead of the correct​:
5ab7151b377c247e5707b80b00474440
...

1. Does this problem still exist?

Yes, I think it's still there with 5.25.8. I see occurrences of 1e+129 in
cpan/Math-BigInt/t/bigintpm.inc in the source.
The last perl I built on that machine is 5.25.7, and it was definitely
present then.

cpan/Math-BigInt/t/bare_mbi ....................................
# Failed test '$x =
Math​::BigInt->new(9.999999999999999999999999999999e+128); $x->bsstr() =
"1e+129"'
# at ./t/bigintpm.inc line 571.
# got​: '9999999999999999999999999999999e+98'
# expected​: '1e+129'
# Looks like you failed 1 test of 3913.
FAILED at test 3723
[snip]
cpan/Math-BigInt/t/bigintpm ....................................
# Failed test '$x =
Math​::BigInt->new(9.999999999999999999999999999999e+128); $x->bsstr() =
"1e+129"'
# at ./t/bigintpm.inc line 571.
# got​: '9999999999999999999999999999999e+98'
# expected​: '1e+129'
# Looks like you failed 1 test of 3919.
FAILED at test 3729
[snip]
cpan/Math-BigInt/t/sub_mbi .....................................
# Failed test '$x =
Math​::BigInt​::Subclass->new(9.999999999999999999999999999999e+128);
$x->bsstr() = "1e+129"'
# at ./t/bigintpm.inc line 571.
# got​: '9999999999999999999999999999999e+98'
# expected​: '1e+129'
# Looks like you failed 1 test of 3918.
FAILED at test 3723

2. Am I correct in thinking that it's specific to the ppc64 architecture?
(I can't reproduce it on x86_64-linux-ld.)

Yes, I think so.
It also pertains only to -Duselongdouble builds of perl - with the "long
double" being the "double-double" arrangement.

$ perl -V​:longdblkind
longdblkind='6';

It's hard to find a value of the form "1e+X" (where X is in the vicinity of
129) that *does* get assigned correctly.
1e+127 does not get assigned correctly either, but I think it's close
enough to not produce the discrepancy​:

$ perl -le '$x = 1e+129;print $x'
9.999999999999999999999999999999e+128
$ perl -le '$x = 1e+128;print $x'
9.999999999999999999999999999999e+127
$ perl -le '$x = 1e+127;print $x'
1e+127

I haven't seen anyone confirm the error, though there probably aren't a
great number of "double-double" builds of perl kicking around.
Perhaps it affects only me.

Cheers,
Rob

[p5pRT]

From @sisyphus

On Wed, 11 Dec 2013 02​:19​:03 -0800, sisyphus wrote​:

Unpacking
the long double reveals that perl assigns​:

5ab7151b377c247e5707b80b00474380
instead of the correct​:
5ab7151b377c247e5707b80b00474440

Actually, I don't think 5ab7151b377c247e5707b80b00474440 is correct either.
It's the value that C's strtold() assigns - but the mpfr library tells me that the correct value (for rounding to nearest, ties to even) is 5ab7151b377c247e5707b80b0047445d.

Having spent some time tonight playing around with various ad-hoc values, it seems that strtold() is little more reliable than perl when it comes to assigning these values.

Cheers,
Rob