Skip Menu |
Report information
Id: 131388
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: jhi <jhi [at] iki.fi>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)

Attachments


From: Jarkko Hietaniemi <jhi [...] iki.fi>
To: perlbug <perlbug [...] perl.org>
Date: Sun, 28 May 2017 09:03:19 +0300
Subject: g++ vs subnormals in 5.26.0
Download (untitled) / with headers
text/plain 1.7k
Something changed in g++ 6 as compared with gcc 6 or g++ 5: the handling of subnormal (denormal) floating point values changed so that the Perl core code parsing (and trying to generate) subnormal numbers does the "flush-to-zero" instead of retaining the subnormal values. t/op/sprintf2.t: ... ok 1491 - subnormal 3e-324 %.1a 0x1.0p-1074 got 0x1.0p-1074 not ok 1492 - subnormal 0x1.fffffffffffffp-1022 %a 0x1.fffffffffffffp-1022 got 0x0p+0 not ok 1493 - subnormal 0x0.fffffffffffffp-1022 %a 0x1.ffffffffffffep-1023 got 0x0p+0 not ok 1494 - subnormal 0x0.7ffffffffffffp-1022 %a 0x1.ffffffffffffcp-1024 got 0x0p+0 not ok 1495 - subnormal 0x0.3ffffffffffffp-1022 %a 0x1.ffffffffffff8p-1025 got 0x0p+0 not ok 1496 - subnormal 0x0.1ffffffffffffp-1022 %a 0x1.ffffffffffffp-1026 got 0x0p+0 not ok 1497 - subnormal 0x0.0ffffffffffffp-1022 %a 0x1.fffffffffffep-1027 got 0x0p+0 ok 1498 ... The problem seems to be the side of parsing the hexfp literals, so toke.c Perl_scan_num(), not on the sv.c sprintf side. $ ./miniperl.gcc -wle 'print unpack("H*",pack("d",0x1.fffffffffffffp-1022))' ffffffffffff1f00 $ ./miniperl.g++ -wle 'print unpack("H*",pack("d",0x1.fffffffffffffp-1022))' 0000000000000000 The behavioural change has been confirmed with both in SUSE Linux (g++ (SUSE Linux) 6.3.1 20170202 [gcc-6-branch revision 245119]) and in OS X (with gcc version 6.3.0 (MacPorts gcc6 6.3.0_2) The discussion in the thread "C++ / G++" in https://www.nntp.perl.org/group/perl.perl5.porters/2017/05/msg244361.html or https://marc.info/?l=perl5-porters&m=149475718717687&w=2 One strange thing noticed that if configured with longdoubles, the g++ 6 build does work correctly: https://www.nntp.perl.org/group/perl.perl5.porters/2017/05/msg244411.html or https://marc.info/?l=perl5-porters&m=149495399107618&w=2
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 429b
Show quoted text
> $ ./miniperl.gcc -wle 'print unpack("H*",pack("d",0x1.fffffffffffffp-1022))' > ffffffffffff1f00 > $ ./miniperl.g++ -wle 'print unpack("H*",pack("d",0x1.fffffffffffffp-1022))' > 0000000000000000
... and the problem is only with the hexadecimal floating point literals: ./miniperl.gcc -wle 'print 0x1.fffffffffffffp-1022' 4.4501477170144e-308 ./miniperl.g++ -wle 'printf "%a\n", 4.4501477170144e-308' 0x1.ffffffffffff5p-1022
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.1k
On Sun, 28 May 2017 06:03:56 GMT, jhi wrote: Show quoted text
> Something changed in g++ 6 as compared with gcc 6 or g++ 5: the handling > of subnormal (denormal) floating point values changed so that the Perl > core code parsing (and trying to generate) subnormal numbers does the > "flush-to-zero" instead of retaining the subnormal values. > > t/op/sprintf2.t: > ... > ok 1491 - subnormal 3e-324 %.1a 0x1.0p-1074 got 0x1.0p-1074 > not ok 1492 - subnormal 0x1.fffffffffffffp-1022 %a > 0x1.fffffffffffffp-1022 got 0x0p+0 > not ok 1493 - subnormal 0x0.fffffffffffffp-1022 %a > 0x1.ffffffffffffep-1023 got 0x0p+0 > not ok 1494 - subnormal 0x0.7ffffffffffffp-1022 %a > 0x1.ffffffffffffcp-1024 got 0x0p+0 > not ok 1495 - subnormal 0x0.3ffffffffffffp-1022 %a > 0x1.ffffffffffff8p-1025 got 0x0p+0 > not ok 1496 - subnormal 0x0.1ffffffffffffp-1022 %a > 0x1.ffffffffffffp-1026 got 0x0p+0 > not ok 1497 - subnormal 0x0.0ffffffffffffp-1022 %a > 0x1.fffffffffffep-1027 got 0x0p+0 > ok 1498 > ... > > The problem seems to be the side of > parsing the hexfp literals, so toke.c Perl_scan_num(), not on the > sv.c sprintf side. > > $ ./miniperl.gcc -wle 'print unpack("H*",pack("d",0x1.fffffffffffffp-1022))' > ffffffffffff1f00 > $ ./miniperl.g++ -wle 'print unpack("H*",pack("d",0x1.fffffffffffffp-1022))' > 0000000000000000 > > The behavioural change has been confirmed with both in SUSE Linux (g++ > (SUSE Linux) 6.3.1 20170202 [gcc-6-branch revision 245119]) > and in OS X (with gcc version 6.3.0 (MacPorts gcc6 6.3.0_2) > > The discussion in the thread "C++ / G++" in > https://www.nntp.perl.org/group/perl.perl5.porters/2017/05/msg244361.html > or https://marc.info/?l=perl5-porters&m=149475718717687&w=2 > > One strange thing noticed that if configured with longdoubles, the g++ 6 > build does work correctly: > https://www.nntp.perl.org/group/perl.perl5.porters/2017/05/msg244411.html > or https://marc.info/?l=perl5-porters&m=149495399107618&w=2
Jarkko, could you supply (at least) the Configure args you used to build the perl used in these tests? Or preferably attach the output of "perl -V"? We should try to reproduce with still newer versions of g++. Thank you very much. -- James E Keenan (jkeenan@cpan.org)
From: Jarkko Hietaniemi <jhi [...] iki.fi>
Subject: Re: [perl #131388] g++ vs subnormals in 5.26.0
Date: Mon, 3 Sep 2018 20:40:41 +0300
To: perlbug-followup [...] perl.org
Download (untitled) / with headers
text/plain 619b
Show quoted text
> > Jarkko, could you supply (at least) the Configure args you used to build the perl used in these tests? Or preferably attach the output of "perl -V"?
Uh, sorry, I am pretty certain I do no more have the setup anywhere, and my builds are ephemeral. But if I go by my usual reflexes the invocation of Configure has been "sh Configure -des -Dcc=g++". Show quoted text
> We should try to reproduce with still newer versions of g++. > > Thank you very much. >
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Mon, 03 Sep 2018 10:33:33 -0700, jkeenan wrote: Show quoted text
> On Sun, 28 May 2017 06:03:56 GMT, jhi wrote:
Show quoted text
> > The problem seems to be the side of > > parsing the hexfp literals, so toke.c Perl_scan_num(), not on the > > sv.c sprintf side.
I agree. I certainly haven't been able to reproduce the behaviour in any C scripts compiled using g++. Show quoted text
> We should try to reproduce with still newer versions of g++.
I see the same with g++ 7.3.0 on Ubuntu-18.04. And it's happening on 5.28.0 and 5.29.2, too, though the problem has been hidden away (via TODO) since sometime prior to the release of 5.28.0 - so that the failures are no longer reported by 'make test'. Comments in op/sprintf2.t claim that "pow(2.0, -1074) returns 0", but I couldn't find anything to substantiate that claim. It's not just subnormals that are affected, either: ~/comp/perl-5.29.2$ ./perl -le 'printf "%a\n", 0x1.0p-1020;' 0x0p+0 though this works as expected when rewritten as: ~/comp/perl-5.29.2$ ./perl -le 'printf "%a\n", 0x1p-1020;' 0x1p-1020 And it's not limited to g++ builds, either. I found a few subnormal values where a gcc-7.3.0 build of 5.29.2 on the same machine (and a gcc-8.1.0 build of 5.29.2 on Windows 7) were also behaving improperly - eg: $ perl -le 'printf "%a\n", 0x1.0p-1074;' 0x0p+0 $ perl -le 'printf "%a\n", 0x1p-1074;' 0x1p-1074 (Same type of behaviour for exponents -1071, -1072, and -1073 on the same 2 machines.) I Configured the g++ builds with "-des -Dcc=g++" (and additionally with "-Dusedevel" for 5.29.2). Cheers, Rob
Date: Tue, 4 Sep 2018 20:48:25 +0100
Subject: Re: [perl #131388] g++ vs subnormals in 5.26.0
To: "sisyphus [...] cpan.org via RT" <perlbug-followup [...] perl.org>
CC: perl5-porters [...] perl.org
From: Dave Mitchell <davem [...] iabyn.com>
Download (untitled) / with headers
text/plain 1.2k
On Tue, Sep 04, 2018 at 07:29:00AM -0700, sisyphus@cpan.org via RT wrote: Show quoted text
> Comments in op/sprintf2.t claim that "pow(2.0, -1074) returns 0", but I couldn't find anything to substantiate that claim.
The commit which added those comments was mine, although can no longer remember the details: commit 38c84d6ad1b77d7b1de424eab465e018c7cef576 Author: David Mitchell <davem@iabyn.com> AuthorDate: Tue May 1 15:28:49 2018 +0100 Commit: David Mitchell <davem@iabyn.com> CommitDate: Tue May 1 15:52:55 2018 +0100 sprintf2.t: mark TODO bad denorm values under g++ Some t/op/sprintf2.t tests were failing under g++. This is due the perl toker interpreting very small literal hex floating pointers as 0 rather than as a subnormal value. For example: perl -le'print "bad" if 0x1.fffffffffffffp-1022 == 0.0' This breaks some of the sprintf2.t tests, so mark them TODO them if the literal value evaluates to zero. Note that this is a bug in the toker/g++/glibc rather than sprintf. The issue is due to the use of pow() in scan_num(): under gcc and plain g++, pow(2.0, -1074) returns the smallest denorm number; however, under 'g++ -ansi', it returns 0.0. -- I thought I was wrong once, but I was mistaken.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 289b
On Tue, 04 Sep 2018 12:48:48 -0700, davem wrote: Show quoted text
> under gcc and plain g++, pow(2.0, -1074) returns the smallest denorm > number; however, under 'g++ -ansi', it returns 0.0.
Yes, you're right. I thought I had checked with the ansi switch last night, but apparently I hadn't. Cheers, Rob
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 176b
On Tue, 04 Sep 2018 12:48:48 -0700, davem wrote: Show quoted text
> The issue is due to the use of pow() in scan_num()
The attached patch to current blead fixes the bug for me. Cheers, Rob
Subject: 0001-toke.c-Cast-I32-to-NV-in-Perl_pow-call.patch
From 9d00f794432f827520b5db60b8a12d897248d1cf Mon Sep 17 00:00:00 2001 From: sisyphus <sisyphus1@optusnet.com.au> Date: Wed, 5 Sep 2018 21:36:29 +1000 Subject: [PATCH] toke.c - Cast I32 to NV in Perl_pow() call --- toke.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/toke.c b/toke.c index 24e614fd50..191a1ce8b9 100644 --- a/toke.c +++ b/toke.c @@ -11221,7 +11221,7 @@ Perl_scan_num(pTHX_ const char *start, YYSTYPE* lvalp) #ifdef HEXFP_UQUAD hexfp_exp -= hexfp_frac_bits; #endif - hexfp_mult = Perl_pow(2.0, hexfp_exp); + hexfp_mult = Perl_pow(2.0, (NV)hexfp_exp); hexfp = TRUE; goto decimal; } -- 2.17.1
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 371b
On Wed, 05 Sep 2018 12:20:20 GMT, sisyphus@cpan.org wrote: Show quoted text
> On Tue, 04 Sep 2018 12:48:48 -0700, davem wrote: >
> > The issue is due to the use of pow() in scan_num()
> > The attached patch to current blead fixes the bug for me. > > Cheers, > Rob >
Created branch for smoke-testing: smoke-me/jkeenan/sisyphus/131388-subnormals -- James E Keenan (jkeenan@cpan.org)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 534b
On Wed, 05 Sep 2018 14:17:46 -0700, jkeenan wrote: Show quoted text
> Created branch for smoke-testing: > > smoke-me/jkeenan/sisyphus/131388-subnormals
If the patch is successful, we will also need to undo Dave's commit (38c84d6ad1b77d7b1de424eab465e018c7cef576) to sprintf2.t that made the failing tests "TODO". In the one report currently available on the new smoke-me branch, I see the line "Test todo-passed:" with no entries following it - so I'm guessing that will list any TODOs that failed. Are g++ builds being smoked ? Cheers, Rob
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Wed, 05 Sep 2018 23:47:32 GMT, sisyphus@cpan.org wrote: Show quoted text
> On Wed, 05 Sep 2018 14:17:46 -0700, jkeenan wrote: >
> > Created branch for smoke-testing: > > > > smoke-me/jkeenan/sisyphus/131388-subnormals
> > If the patch is successful, we will also need to undo Dave's commit > (38c84d6ad1b77d7b1de424eab465e018c7cef576) to sprintf2.t that made the > failing tests "TODO". >
Just now I reverted that commit and pushed it back to origin in same branch. Show quoted text
> In the one report currently available on the new smoke-me branch, I > see the line "Test todo-passed:" with no entries following it - so I'm > guessing that will list any TODOs that failed. > > Are g++ builds being smoked ? >
FBOW, there is no centralized schema/matrix of platforms/C-compilers being smoked. All smoke testing rigs are maintained by individual volunteers; none (any longer) by perl.org or perl5-porters. So it depends on what individual testers have had the time and energe to set up. My recommendation: 1. Based on the discussion in this RT and in any other relevant places on list, make a list of platform/C-compiler combinations which need to be tested to thoroughly exercise the branch. 2. After you've made that list -- not before, which would introduce a potential bias -- go to http://perl.develop-help.com/?b=smoke-me%2Fjkeenan%2Fsisyphus%2F131388-subnormals and review the results. 3. Then make a list of platform/C-compiler combos which remain to be tested. Post that back in this RT. We'll see what we can do to accommodate you and the needs of the RT. Thank you very much. -- James E Keenan (jkeenan@cpan.org)
RT-Send-CC: perl5-porters [...] perl.org
On Thu, 06 Sep 2018 02:20:46 GMT, jkeenan wrote: Show quoted text
> On Wed, 05 Sep 2018 23:47:32 GMT, sisyphus@cpan.org wrote:
> > On Wed, 05 Sep 2018 14:17:46 -0700, jkeenan wrote: > >
> > > Created branch for smoke-testing: > > > > > > smoke-me/jkeenan/sisyphus/131388-subnormals
> > > > If the patch is successful, we will also need to undo Dave's commit > > (38c84d6ad1b77d7b1de424eab465e018c7cef576) to sprintf2.t that made > > the > > failing tests "TODO". > >
> > Just now I reverted that commit and pushed it back to origin in same > branch. >
> > In the one report currently available on the new smoke-me branch, I > > see the line "Test todo-passed:" with no entries following it - so > > I'm > > guessing that will list any TODOs that failed. > > > > Are g++ builds being smoked ? > >
> > FBOW, there is no centralized schema/matrix of platforms/C-compilers > being smoked. All smoke testing rigs are maintained by individual > volunteers; none (any longer) by perl.org or perl5-porters. So it > depends on what individual testers have had the time and energe to set > up. > > My recommendation: > > 1. Based on the discussion in this RT and in any other relevant places > on list, make a list of platform/C-compiler combinations which need to > be tested to thoroughly exercise the branch. > > 2. After you've made that list -- not before, which would introduce a > potential bias -- go to http://perl.develop-help.com/?b=smoke- > me%2Fjkeenan%2Fsisyphus%2F131388-subnormals and review the results. > > 3. Then make a list of platform/C-compiler combos which remain to be > tested. Post that back in this RT. We'll see what we can do to > accommodate you and the needs of the RT. > > Thank you very much.
One other consideration: Your patch added no new tests, though we just reverted the TODO-ing of some older tests. It may be the case -- I haven't really followed the details of this RT that closely -- that to fully resolve the problem we need to write *new* tests. If so, we should add them to this branch and do additional smoke testing. Thank you very much. -- James E Keenan (jkeenan@cpan.org)
From: Jarkko Hietaniemi <jhi [...] iki.fi>
To: perlbug-followup [...] perl.org
Date: Thu, 6 Sep 2018 06:28:06 +0300
Subject: Re: [perl #131388] g++ vs subnormals in 5.26.0
Download (untitled) / with headers
text/plain 1.1k
Show quoted text
> Are g++ builds being smoked ?
>>
> > FBOW, there is no centralized schema/matrix of platforms/C-compilers being smoked. All smoke testing rigs are maintained by individual volunteers; none (any longer) by perl.org or perl5-porters. So it depends on what individual testers have had the time and energe to set up. > > My recommendation: > > 1. Based on the discussion in this RT and in any other relevant places on list, make a list of platform/C-compiler combinations which need to be tested to thoroughly exercise the branch.
*All* the combinations is of course far too large a number, sadly. Also, I don't think this discussion should be limited to this one or any one single branch. In general, I think doing first some varying on the platform, and then some varying on the compiler, would be good. The basic boring combination is gcc (or clang) on x86-64 on linux (and therefore glibc). Anything beyond that would be very useful. Some degrees to consider: - x86-32 - non-x86 - bigendian - some CPU with stricter alignment than x86 - gcc - clang - non-gcc-compatible-cc - C++ compiler - cross-compiler - non-Linux - non-UNIX - non-UNIX-other-than-windows - long double - threads
Subject: Re: [perl #131388] g++ vs subnormals in 5.26.0
Date: Thu, 6 Sep 2018 12:04:32 +0100
To: James E Keenan via RT <perlbug-followup [...] perl.org>
CC: perl5-porters [...] perl.org
From: Dave Mitchell <davem [...] iabyn.com>
Download (untitled) / with headers
text/plain 883b
On Wed, Sep 05, 2018 at 07:25:55PM -0700, James E Keenan via RT wrote: Show quoted text
> One other consideration: Your patch added no new tests, though we just > reverted the TODO-ing of some older tests. It may be the case -- I > haven't really followed the details of this RT that closely -- that to > fully resolve the problem we need to write *new* tests. If so, we > should add them to this branch and do additional smoke testing.
The best thing to do would be to convert the TODO condition into a test, i.e. if $f == 0.0 && $t->[2] ne '0x0p+0'; so that if this condition arises again it will be quicker to diagnose. e.g. ok($f != 0.0 || $t->[2] eq '0x0p+0', "denorm value shouldn't be zero: $t->[0]"); -- "I do not resent criticism, even when, for the sake of emphasis, it parts for the time with reality". -- Winston Churchill, House of Commons, 22nd Jan 1941.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Wed, 05 Sep 2018 19:25:55 -0700, jkeenan wrote: Show quoted text
> One other consideration: Your patch added no new tests, though we > just reverted the TODO-ing of some older tests. It may be the case -- > I haven't really followed the details of this RT that closely -- that > to fully resolve the problem we need to write *new* tests. If so, we > should add them to this branch and do additional smoke testing.
I suppose, to be thorough, we should also be performing similar tests for subnormal NV values on -Duselongdouble and -Dusequadmath builds. I'll work on patching the blead version of sprintf2.t to do this - and to also incorporate Dave's suggestion re converting the TODO into actual tests. Attached is try.c which, when built with 'g++ -ansi' demonstrates the problem - and also demonstrates that the cast to double fixes the issue. I asked about the validity of the way that 'g++ -ansi' handled that script on the gcc-help mailing list (see https://gcc.gnu.org/ml/gcc-help/2018-09/msg00031.html). The responses were not exactly definitive, but I gathered it was felt that there was no immediate need to alter the way that g++ was doing anything. As a result of that thread, I did begin to wonder why it is that g++ builds of perl invoke the '-ansi' switch (which is actually equivalent to '-std=c++89'). Is this setting something that's easily configured differently ? It also seemed strange that, having built perl with 'g++ -ansi', any XS modules subsequently installed, will be built without the '-ansi' switch. Cheers, Rob
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 242b
On Tue, 11 Sep 2018 19:11:02 -0700, sisyphus@cpan.org wrote: Show quoted text
> Attached is try.c which, when built with 'g++ -ansi' demonstrates the > problem - and also demonstrates that the cast to double fixes the > issue.
Eventually ... Cheers, Rob
Subject: try.c
Download try.c
application/octet-stream 186b

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1019b
On Tue, 11 Sep 2018 19:11:02 -0700, sisyphus@cpan.org wrote: Show quoted text
> I suppose, to be thorough, we should also be performing similar tests > for subnormal NV values on -Duselongdouble and -Dusequadmath builds.
On closer inspection I can see that's already happening. In fact, I don't see any need to make any alteration to the version of t/op/sprintf2.t that is currently in the smoke-me/jkeenan/sisyphus/131388-subnormals branch ... except, perhaps, for one unrelated observation: At line 897 of smoke-me/jkeenan/sisyphus/131388-subnormals/t/op/sprintf2.t, we begin 7 tests on usequadmath builds in response to ticket #128843. I believe those tests could also be applied to uselongdouble builds where the long double conforms to the IEEE 754 standard. I'm not bothered one way or the other about this, and I don't have access to a system that provides such long doubles so I can't test it. But I'm attaching the patch (against smoke-me/jkeenan/sisyphus/131388-subnormals/t/op/sprintf2.t) for review, anyway. Cheers, Rob
Subject: 0001-expand-scope-of-quadmath-tests-in-t-op-sprintf2.t.patch
From fd3dce7e0d0640f397cf687b00f8d3e4d58aacc0 Mon Sep 17 00:00:00 2001 From: sisyphus <sisyphus1@optusnet.com.au> Date: Sat, 22 Sep 2018 22:08:17 +1000 Subject: [PATCH] expand scope of quadmath tests in t/op/sprintf2.t --- t/op/sprintf2.t | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/t/op/sprintf2.t b/t/op/sprintf2.t index 5fb7597..6d498db 100644 --- a/t/op/sprintf2.t +++ b/t/op/sprintf2.t @@ -896,7 +896,9 @@ SKIP: { # quadmath tests for rt.perl.org #128843 SKIP: { - skip "need quadmath", 7, unless $Config{usequadmath}; + skip "need IEEE 754 NV", 7, + unless ($Config{usequadmath} || + ($Config{uselongdouble} && $Config{longdblkind} > 0 && $Config{longdblkind} < 3)); is(sprintf("%a", eval '0x1p-16382'), '0x1p-16382'); # last normal -- 2.1.4
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.7k
On Sat, 22 Sep 2018 12:14:40 GMT, sisyphus@cpan.org wrote: Show quoted text
> On Tue, 11 Sep 2018 19:11:02 -0700, sisyphus@cpan.org wrote: >
> > I suppose, to be thorough, we should also be performing similar tests > > for subnormal NV values on -Duselongdouble and -Dusequadmath builds.
> > On closer inspection I can see that's already happening. > In fact, I don't see any need to make any alteration to the version of > t/op/sprintf2.t that is currently in the smoke- > me/jkeenan/sisyphus/131388-subnormals branch ... except, perhaps, for > one unrelated observation: > > At line 897 of smoke-me/jkeenan/sisyphus/131388- > subnormals/t/op/sprintf2.t, we begin 7 tests on usequadmath builds in > response to ticket #128843. > I believe those tests could also be applied to uselongdouble builds > where the long double conforms to the IEEE 754 standard. > I'm not bothered one way or the other about this, and I don't have > access to a system that provides such long doubles so I can't test it. > But I'm attaching the patch (against smoke-me/jkeenan/sisyphus/131388- > subnormals/t/op/sprintf2.t) for review, anyway. > > Cheers, > Rob
Last night I applied your patch to the smoke-me/jkeenan/sisyphus/131388-subnormals branch and pushed it to the origin for smoke-testing. Most smoke-test results are good, but I got one failure on my my own FreeBSD-11 smoke-testing rig. See: http://perl5.test-smoke.org/report/70990. Where the configuration was: ##### -des -Dusedevel -Duseithreads -Doptimize=-O2 -pipe -fstack-protector -fno-strict-aliasing -Dcc=g++ -Dusemorebits -DDEBUGGING ##### ... I got this error: ##### Test failures: ~~ ../dist/threads/t/exit.t .................................... FAILED 14 [perlio] -Duseithreads -Doptimize="-O2 -pipe -fstack-protector -fno-strict-aliasing" -Dcc="g++" -Dusemorebits DEBUGGING ##### Test 14 in dist/threads/t/exit.t is coded like this: ##### $out = run_perl(prog => 'use threads 2.21 qw(exit thread_only);' . 'threads->create(sub {' . ' threads->set_thread_exit_only(0);' . ' exit(99);' . '});' . 'sleep(1);' . 'exit(86);', nolib => ($ENV{PERL_CORE}) ? 0 : 1, switches => ($ENV{PERL_CORE}) ? [] : [ '-Mblib' ], stderr => 1); { local $TODO = 'VMS exit semantics not like POSIX exit semantics' if $^O eq 'VMS'; is($?>>8, 99, "set_thread_exit_only(0)"); } ##### I then went to my git checkout on the same machine, checked out this branch, built perl with the same configuration and ran the test file through the harness. It PASSed. So the test failure in the smoke-test may be a transient failure due to resource limitations. ISTR seeing such failures in that file previously. Thank you very much. -- James E Keenan (jkeenan@cpan.org)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 892b
On Sun, 23 Sep 2018 05:37:52 -0700, jkeenan wrote: Show quoted text
> So the test failure in the smoke-test may be a transient failure due > to resource limitations.
I don't know what would have caused that failure, and I'll happily go along with "resource limitations". Note that the patch was to t/op/sprintf2.t and that the only failures we could therefore attribute to it would have to be t/op/sprintf2.t failures. I don't think there are any smokers where $Config{longdblkind} is either 1 or 2, so I don't think my change to t/op/sprintf2.t will make any difference to them. Hopefully I'm wrong about that - I'd be delighted to learn that there's at least 1 smoker out there that has the quadruple precision, 128-bit, IEEE 754 long double where $Config{longdblkind} is being set correctly to 1 or 2. The various $Config{longdblkind} values are explained in the Config.pm documentation. Cheers, Rob
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 482b
It occurs to me that the toke.c patch should also include a comment that the explicit cast to NV is needed for some g++ builds. Without that comment, it's possible that someone will remove that explicit cast in future. If the fix of casting to NV is deemed unsatisfactory, I should add that the bug could probably also be fixed in toke.c by replacing "Perl_pow(2.0,hexfp_exp)" with "Perl_ldexp(1.0,hexfp_exp)" though this would require another round of smoke testing. Cheers, Rob


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org