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
Perl regression bug since 5.13.11 (masked by CoW since 5.19.1) #13921
Comments
From @devenThe following test case demonstrates a Perl regression bug, evidently This is perl 5, version 18, subversion 2 (v5.18.2) built for $ cat testcase use List::MoreUtils qw[minmax]; my @numbers = (20140613); my @numbers_minmax = minmax @numbers; print "@numbers_minmax" eq $check ? "ok 1\n" : "not ok 1\n"; After I isolated this test case under Perl 5.18.2, George Greer (my commit acdea6f [perl #82111] de-pessimise some my @array = ... Due to obscure closure and goto tricks, it's sometimes possible for the This commit speeds it up again by adding a run-time check to pp_aassign See also #70171. After further research, he determined that the bug appears to be masked commit 13b0f67 re-enable Copy-on-Write by default. COW was first introduced (and enabled by default) in 5.17.7. By re-enabling it now, early in the 5.19.x release cycle, hopefully it This commit mainly reverts 9f351b4 and e1fd413 (with George confirmed that the bug still exists by building blead (v5.21.1 He also mentioned that a 5.18.3 release is planned; is there any chance a Deven |
From @iabynOn Fri, Jun 13, 2014 at 12:41:58PM -0700, Deven T. Corzine wrote:
It's a more general problem, and assignment to an array is only one aspect of my $a = "foo"; which outputs under various perls: v5.12.5: [foo;foo] the map creates a TEMP copy of $a; the [0,0] list slice pushes that copy In 5.20.0 and later with COW enabled (the default), when map makes a TEMP copy It may be possible to construct a scenario that shows a similar issue in Fixing this for maint releases would be hard. Simply reverting acdea6f My acdea6f commit was a final iteration of that. We had realised my @a = ($x, $y); couldn't be guaranteed (at compile time) not to have common elements, much f(); (that may not be the exact thing that reproduces it, but it was something so 'my @a = ...' was pessmimsed. My commit allowed that to be -- |
The RT System itself - Status changed from 'new' to 'open' |
From @devenOn Fri, Jun 13, 2014 at 5:31 PM, Dave Mitchell <davem@iabyn.com> wrote:
So what's the solution? Prioritizing performance over correctness doesn't Deven |
From @LeontOn Fri, Jun 13, 2014 at 11:31 PM, Dave Mitchell <davem@iabyn.com> wrote:
Yet another bug in the category "because the perl stack isnt refcounted" :-( Leon |
From @iabynOn Tue, Jun 17, 2014 at 10:17:51AM -0400, Deven T. Corzine wrote:
I can't think of an easy solution. The string swiping code has been there sub f { my $t = f() would involve copying the long string multiple times. Its an optimisation The other part of the problem is that perl's argument stack isn't The only easy way to fix this for your use-case would be for -- |
@iabyn - Status changed from 'open' to 'resolved' |
From @iabynOn Wed, Jun 18, 2014 at 12:45:17PM +0100, Dave Mitchell wrote:
Since then I've heavily reworked list assignment and I think all the -- |
Migrated from rt.perl.org#122099 (status was 'resolved')
Searchable as RT122099$
The text was updated successfully, but these errors were encountered: