Bleadperl v5.21.3-432-g8a00edd breaks RJBS/Color-Scheme-1.06.tar.gz #14078

p5pRT · 2014-09-08T08:05:21Z

Migrated from rt.perl.org#122730 (status was 'resolved')

Searchable as RT122730$

p5pRT · 2014-09-08T08:05:21Z

From @andk

git bisect

commit 8a00edd
Author: Jarkko Hietaniemi <jhi@iki.fi>
Date: Wed Sep 3 18:45:29 2014 -0400

POSIX math: have the Perl_func wrappers for the C89 math, too.

Note: fails only on nvsize == 16 so far

smple fail report

http://www.cpantesters.org/cpan/report/ae344c56-34d3-11e4-9aac-71b9cc4edbc1

perl -V

Summary of my perl5 (revision 5 version 21 subversion 4) configuration:
Commit id: c7da42c
Platform:
osname=linux, osvers=3.14-2-amd64, archname=x86_64-linux-ld
uname='linux k83 3.14-2-amd64 #1 smp debian 3.14.15-2 (2014-08-09) x86_64 gnulinux '
config_args='-Dprefix=/home/sand/src/perl/repoperls/installed-perls/perl/v5.21.3-458-gc7da42c/127e -Dmyhostname=k83 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Uuseithreads -Duselongdouble -DDEBUGGING=-g'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
use64bitint=define, use64bitall=define, uselongdouble=define
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2',
optimize='-O2 -g',
cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.9.1', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3
ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t', lseeksize=8
alignbytes=16, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=libc-2.19.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.19'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl):
Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_MALLOC_WRAP
PERL_NEW_COPY_ON_WRITE 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 Sep 5 2014 03:28:30
%ENV:
PERL="/tmp/basesmoker-reloperl-7oyk/bin/perl"
PERL5LIB=""
PERL5OPT=""
PERL5_CPANPLUS_IS_RUNNING="16238"
PERL5_CPAN_IS_RUNNING="16238"
PERL_MM_USE_DEFAULT="1"
@INC:
/home/sand/src/perl/repoperls/installed-perls/perl/v5.21.3-458-gc7da42c/127e/lib/site_perl/5.21.4/x86_64-linux-ld
/home/sand/src/perl/repoperls/installed-perls/perl/v5.21.3-458-gc7da42c/127e/lib/site_perl/5.21.4
/home/sand/src/perl/repoperls/installed-perls/perl/v5.21.3-458-gc7da42c/127e/lib/5.21.4/x86_64-linux-ld
/home/sand/src/perl/repoperls/installed-perls/perl/v5.21.3-458-gc7da42c/127e/lib/5.21.4
.

--
andreas

p5pRT · 2014-09-08T11:23:42Z

From @jhi

On Monday-201409-08, 4:05, (Andreas J. Koenig) (via RT) wrote:

# New Ticket Created by (Andreas J. Koenig)
# Please include the string: [perl #122730]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=122730 >

git bisect
----------
commit 8a00edd
Author: Jarkko Hietaniemi <jhi@iki.fi>
Date: Wed Sep 3 18:45:29 2014 -0400
 POSIX math&#8203;: have the Perl\_func wrappers for the C89 math\, too\.
Note: fails only on nvsize == 16 so far

And that would be expected.

So what the change did was to consistently apply the Perl_ math wrappers
like Perl_exp().

Before the change: regardless of NV size (double or long double), exp()
was applied.

After the change: depending on USE_LONG_DOUBLE, the vanilla or the long
double version (exp or expl) is applied.

The first diff is last-bit diff:

# * 5|'2412b2' |'2412b3' *

but the second one looks like more:

# * 9|'00b27d' |'00b37d' *

I haven't looked at what math the test is applying.

smple fail report
-----------------
http://www.cpantesters.org/cpan/report/ae344c56-34d3-11e4-9aac-71b9cc4edbc1

perl -V
-------
Summary of my perl5 (revision 5 version 21 subversion 4) configuration:
Commit id: c7da42c
Platform:
osname=linux, osvers=3.14-2-amd64, archname=x86_64-linux-ld
uname='linux k83 3.14-2-amd64 #1 smp debian 3.14.15-2 (2014-08-09) x86_64 gnulinux '
config_args='-Dprefix=/home/sand/src/perl/repoperls/installed-perls/perl/v5.21.3-458-gc7da42c/127e -Dmyhostname=k83 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Uuseithreads -Duselongdouble -DDEBUGGING=-g'
hint=recommended, useposix=true, d_sigaction=define
useithreads=undef, usemultiplicity=undef
use64bitint=define, use64bitall=define, uselongdouble=define
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2',
optimize='-O2 -g',
cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
ccversion='', gccversion='4.9.1', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16, longdblkind=3
ivtype='long', ivsize=8, nvtype='long double', nvsize=16, Off_t='off_t', lseeksize=8
alignbytes=16, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
libc=libc-2.19.so, so=so, useshrplib=false, libperl=libperl.a
gnulibc_version='2.19'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl):
Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_MALLOC_WRAP
PERL_NEW_COPY_ON_WRITE 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 Sep 5 2014 03:28:30
%ENV:
PERL="/tmp/basesmoker-reloperl-7oyk/bin/perl"
PERL5LIB=""
PERL5OPT=""
PERL5_CPANPLUS_IS_RUNNING="16238"
PERL5_CPAN_IS_RUNNING="16238"
PERL_MM_USE_DEFAULT="1"
@INC:
/home/sand/src/perl/repoperls/installed-perls/perl/v5.21.3-458-gc7da42c/127e/lib/site_perl/5.21.4/x86_64-linux-ld
/home/sand/src/perl/repoperls/installed-perls/perl/v5.21.3-458-gc7da42c/127e/lib/site_perl/5.21.4
/home/sand/src/perl/repoperls/installed-perls/perl/v5.21.3-458-gc7da42c/127e/lib/5.21.4/x86_64-linux-ld
/home/sand/src/perl/repoperls/installed-perls/perl/v5.21.3-458-gc7da42c/127e/lib/5.21.4
.

p5pRT · 2014-09-08T11:23:42Z

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

p5pRT · 2014-09-27T09:16:07Z

From @andk

Also affected: MUIR/modules/Net-Netmask-1.9021.tar.gz (only long double versions)

--
andreas

p5pRT · 2015-03-07T02:46:28Z

From @jkeenan

On Sat Sep 27 02:16:07 2014, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:

Also affected: MUIR/modules/Net-Netmask-1.9021.tar.gz (only long
double versions)

I see that on Andreas' smokers, both RJBS/Color-Scheme and MUIR/Net-Netmask are PASSing on their x86_64-linux and x86_64-linux-thread-multi builds -- but failing on their x86_64-linux-ld and x86_64-linux-multi-thread-ld builds.

Can anyone explain what difference the '-ld' build makes and how it might explain these failures?

Thank you very much.

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

p5pRT · 2015-03-07T04:02:10Z

From @andk

On Fri, 6 Mar 2015 18:46:29 -0800, "James E Keenan via RT" <perlbug-followup@perl.org> said:

> On Sat Sep 27 02:16:07 2014, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:

Also affected: MUIR/modules/Net-Netmask-1.9021.tar.gz (only long
double versions)

> I see that on Andreas' smokers, both RJBS/Color-Scheme and MUIR/Net-Netmask are PASSing on their x86_64-linux and x86_64-linux-thread-multi builds -- but failing on their x86_64-linux-ld and x86_64-linux-multi-thread-ld builds.

> Can anyone explain what difference the '-ld' build makes and how it might explain these failures?

> Thank you very much.

ld = -Duselongdouble

The sentence 'Note: fails only on nvsize == 16 so far' in the ticket is
closely related to this because on x64 uselongdouble implies nvsize=16.

--
andreas

p5pRT · 2015-03-08T23:53:59Z

From @rjbs

* Jarkko Hietaniemi <jhi@iki.fi> [2014-09-08T07:22:54]

After the change: depending on USE_LONG_DOUBLE, the vanilla or the long
double version (exp or expl) is applied.

The first diff is last-bit diff:

# * 5|'2412b2' |'2412b3' *

but the second one looks like more:

# * 9|'00b27d' |'00b37d' *

So, it's not worse, because these strings are RRGGBB strings, and each pair is
computed independently. So, the change is from 0xb2 to 0xb3. Last bit, again.

I haven't looked at what math the test is applying.

I wrote up a longer description of this problem in a github issue (link below)
but what it comes down to is that on one perl, 178.5 rounds to 178, and on one
to 179.

I am not seeing any distinction between the two 178.5s using %g or Devel::Peek.

rjbs/Color-Scheme#3

On one hand, I could allow for each byte to vary by 1, but this change seem
very odd. Perhaps you could have a look at the branch mentioned in the ticket
(debug-noise).

--
rjbs

p5pRT · 2015-03-09T01:58:16Z

From @jhi

I am not seeing any distinction between the two 178.5s using %g or Devel::Peek.

%g lies, often, even if you squeeze more digits into it.
(Binary-to-decimal by necessity includes cheating.)

Could you try the two 178.5s with the new %a format, it tells you even
the last bit, no cheating.

p5pRT · 2015-03-09T02:08:22Z

From @rjbs

* Jarkko Hietaniemi <jhi@iki.fi> [2015-03-08T21:57:41]

I am not seeing any distinction between the two 178.5s using %g or
Devel::Peek.

%g lies, often, even if you squeeze more digits into it. (Binary-to-decimal
by necessity includes cheating.)

Could you try the two 178.5s with the new %a format, it tells you even the
last bit, no cheating.

Delighted to!

nvsize=8:

0 179 125 [0 178.5 124.95] <0x1.65p+7 0x1.0cccccccccccdp+0 0x1p+0>

nvsize=16:

0 178 125 [0 178.5 124.95] <0xb.28p+4 0x8.666666666666666p-3 0x8p-3>

Stupid floats.

--
rjbs

p5pRT · 2015-03-23T12:54:20Z

From @rjbs

This is solved in Color-Scheme 1.07

--
rjbs

p5pRT · 2015-03-23T12:54:23Z

@rjbs - Status changed from 'open' to 'resolved'

p5pRT closed this as completed Mar 23, 2015

p5pRT added the Severity Low label Oct 19, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bleadperl v5.21.3-432-g8a00edd breaks RJBS/Color-Scheme-1.06.tar.gz #14078

Bleadperl v5.21.3-432-g8a00edd breaks RJBS/Color-Scheme-1.06.tar.gz #14078

p5pRT commented Sep 8, 2014

p5pRT commented Sep 8, 2014

p5pRT commented Sep 8, 2014

p5pRT commented Sep 8, 2014

p5pRT commented Sep 27, 2014

p5pRT commented Mar 7, 2015

p5pRT commented Mar 7, 2015

p5pRT commented Mar 8, 2015

p5pRT commented Mar 9, 2015

p5pRT commented Mar 9, 2015

p5pRT commented Mar 23, 2015

p5pRT commented Mar 23, 2015

Bleadperl v5.21.3-432-g8a00edd breaks RJBS/Color-Scheme-1.06.tar.gz #14078

Bleadperl v5.21.3-432-g8a00edd breaks RJBS/Color-Scheme-1.06.tar.gz #14078

Comments

p5pRT commented Sep 8, 2014

p5pRT commented Sep 8, 2014

From @andk

p5pRT commented Sep 8, 2014

From @jhi

p5pRT commented Sep 8, 2014

p5pRT commented Sep 27, 2014

From @andk

p5pRT commented Mar 7, 2015

From @jkeenan

p5pRT commented Mar 7, 2015

From @andk

p5pRT commented Mar 8, 2015

From @rjbs

p5pRT commented Mar 9, 2015

From @jhi

p5pRT commented Mar 9, 2015

From @rjbs

p5pRT commented Mar 23, 2015

From @rjbs

p5pRT commented Mar 23, 2015