From @sisyphus

Hi,

This is a long standing issue for me with my PPC long double (double double)
builds of perl - going back to perl-5.18.0 (and probably beyond).

Assuming that an exponent of +129 is no more (and no less) "special" than an
exponent of +127, here's the patch I would like to see applied​:

==========================================================

--- bigintpm.inc_orig   2015-07-24 20:56:00 +1000
+++ bigintpm.inc        2015-07-25 00:08:20 +1000
@@ -437,10 +437,10 @@

###############################################################################

# test for whitespace including newlines to be handled correctly

==========================================================

My reason is pretty simple.
Perl assigns the wrong value for 1e+129 on these double double builds​:

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

As a consequence, the following perl test scripts inevitably fail (just one
test for each script)​:

../dist/Math-BigInt/t/bare_mbi.t
../dist/Math-BigInt/t/bigintpm.t
../dist/Math-BigInt/t/sub_mbi.t

These failures do not reflect a problem with Math​::BigInt - they are simply
a reflection of the fact that perl has assigned an incorrect value (to $z,
in bigintpm.inc).

I believe that such small errors are common to most systems - though the
details vary between different systems.
And FC has assured me, in the past, that there are no plans to fix these
errors.

It so happens that a similar problem occurs with an exponent of +128 (and
+130) - an exponent of +127 being the first I came across that allows those
3 test scripts to pass all tests. (Even then, I think perl gets it wrong ...
but at least it's close enough as to allow the tests to pass.)

There's no great problem for me in having those tests fail, except that
those failures can obscure the fact that another test script might also have
failed - especially if one tends to be (like me) not as attentive to the
test summary as one ought to be.

Here's the perl -V​:

Summary of my perl5 (revision 5 version 23 subversion 1) configuration​:

  Platform​:
  osname=linux, osvers=3.2.0-4-powerpc64,
archname=ppc64-linux-thread-multi-ld
  uname='linux debian-sis 3.2.0-4-powerpc64 #1 smp debian 3.2.68-1+deb7u2
ppc64 gnulinux '
  config_args='-des -Duse64bitint -Dusethreads -Duselongdouble -Duse64bitall
-Dcc=gcc -m64 -Dprefix=/home/sisyphus-sis/bleadperl -Dusedevel'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  use64bitint=define, use64bitall=define, uselongdouble=define
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='gcc -m64', ccflags
='-D_REENTRANT -D_GNU_SOURCE -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='-D_REENTRANT -D_GNU_SOURCE -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/gcc/powerpc-linux-gnu/4.6/include-fixed
/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 MULTIPLICITY PERLIO_LAYERS
  PERL_COPY_ON_WRITE PERL_DONT_CREATE_GVSV
  PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
  PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
  PERL_PRESERVE_IVUV PERL_USE_DEVEL USE_64_BIT_ALL
  USE_64_BIT_INT USE_ITHREADS 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 USE_REENTRANT_API
  Built under linux
  Compiled at Jul 23 2015 21​:10​:35
  @​INC​:
  /home/sisyphus-sis/bleadperl/lib/site_perl/5.23.1/ppc64-linux-thread-multi-ld
  /home/sisyphus-sis/bleadperl/lib/site_perl/5.23.1
  /home/sisyphus-sis/bleadperl/lib/5.23.1/ppc64-linux-thread-multi-ld
  /home/sisyphus-sis/bleadperl/lib/5.23.1
  /home/sisyphus-sis/bleadperl/lib/site_perl

Cheers,
Rob

From @sisyphus

-----Original Message-----
From​: Sisyphus (via RT)
Sent​: Saturday, July 25, 2015 12​:55 AM
To​: bugs-bitbucket@​rt.perl.org
Subject​: [perl #125678] Perl-5.23.1​: Requesting a small change to
dist/Math-BigInt/t/bigintpm.inc (in perl source test suite)

Perl assigns the wrong value for 1e+129 on these double double builds​:

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

As a consequence, the following perl test scripts inevitably fail (just
one test for each script)​:

../dist/Math-BigInt/t/bare_mbi.t
../dist/Math-BigInt/t/bigintpm.t
../dist/Math-BigInt/t/sub_mbi.t

I meant to also provide the actual diagnostic for that failing test in those
3 test scripts. It is​:

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

Cheers,
Rob

From @jkeenan

On Fri Jul 24 07​:55​:32 2015, sisyphus wrote​:

Hi,

This is a long standing issue for me with my PPC long double (double
double)
builds of perl - going back to perl-5.18.0 (and probably beyond).

Assuming that an exponent of +129 is no more (and no less) "special"
than an
exponent of +127, here's the patch I would like to see applied​:

==========================================================

--- bigintpm.inc_orig 2015-07-24 20​:56​:00 +1000
+++ bigintpm.inc 2015-07-25 00​:08​:20 +1000
@​@​ -437,10 +437,10 @​@​

$z = 1050000000000000; # may be int on systems with 64bit?
$x = $class->new($z); is ($x->bsstr(),'105e+13'); # not 1.05e+15
-$z = 1e+129; # definitely a float (may fail on UTS)
+$z = 1e+127; # definitely a float (may fail on UTS)
# don't compare to $z, since some Perl versions stringify $z into
something
# like '1.e+129' or something equally ugly
-$x = $class->new($z); is ($x->bsstr(),'1e+129');
+$x = $class->new($z); is ($x->bsstr(),'1e+127');

###############################################################################

# test for whitespace including newlines to be handled correctly

==========================================================

My reason is pretty simple.
Perl assigns the wrong value for 1e+129 on these double double builds​:

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

As a consequence, the following perl test scripts inevitably fail
(just one
test for each script)​:

../dist/Math-BigInt/t/bare_mbi.t
../dist/Math-BigInt/t/bigintpm.t
../dist/Math-BigInt/t/sub_mbi.t

These failures do not reflect a problem with Math​::BigInt - they are
simply
a reflection of the fact that perl has assigned an incorrect value (to
$z,
in bigintpm.inc).

I believe that such small errors are common to most systems - though
the
details vary between different systems.
And FC has assured me, in the past, that there are no plans to fix
these
errors.

It so happens that a similar problem occurs with an exponent of +128
(and
+130) - an exponent of +127 being the first I came across that allows
those
3 test scripts to pass all tests. (Even then, I think perl gets it
wrong ...
but at least it's close enough as to allow the tests to pass.)

There's no great problem for me in having those tests fail, except
that
those failures can obscure the fact that another test script might
also have
failed - especially if one tends to be (like me) not as attentive to
the
test summary as one ought to be.

Pinging contributors to Math​::BigInt to request evaluation of this patch to the test suite.

Thank you very much.

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

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