Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
p5pRT opened this issue Dec 11, 2013 · 5 comments
Open

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

p5pRT opened this issue Dec 11, 2013 · 5 comments

Comments

@p5pRT
Copy link

p5pRT commented Dec 11, 2013

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

Searchable as RT120758$

@p5pRT
Copy link
Author

p5pRT commented Dec 11, 2013

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
Copy link
Author

p5pRT commented Jan 2, 2017

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
Copy link
Author

p5pRT commented Jan 2, 2017

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

@p5pRT
Copy link
Author

p5pRT commented Jan 2, 2017

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
Copy link
Author

p5pRT commented Dec 11, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant