summaryrefslogtreecommitdiff
path: root/op.c
Commit message (Collapse)AuthorAgeFilesLines
* op.c:newCONSTSUB: Stop using CopFILESV for CvFILEFather Chrysostomos2013-08-051-5/+0
| | | | | | | | | | | | CopFILESV points to *{"_<filename"}, which can be modified from perl space. CopFILE points to the third character of *{"_<filename"}{NAME}. Ithreads were already using CopFILE. Make non-threaded builds do the same. This makes things a little more robust. CvFILE is not actually used anywhere as far as I can tell, so I cannot easily test this.
* op.c:aassign_common_vars: merge duplicate codeFather Chrysostomos2013-08-051-10/+6
| | | | We are just asking for bugs to creep in by repeating it like this.
* op.c: correct commentFather Chrysostomos2013-08-051-1/+1
|
* [perl #117855] Store CopFILEGV in a pad under ithreadsFather Chrysostomos2013-08-051-15/+51
| | | | | | | | | | | | | | | | This saves having to allocate a separate string buffer for every cop (control op; every statement has one). Under non-threaded builds, every cop has a pointer to the GV for that source file, namely *{"_<filename"}. Under threaded builds, the name of the GV used to be stored instead. Now we store an offset into the per-interpreter PL_filegvpad, which points to the GV. This makes no significant speed difference, but it reduces mem- ory usage.
* Revert "[perl #119043] Exempt shared hash key consts from ro"Father Chrysostomos2013-08-031-3/+1
| | | | | | | | | | | | | | | | | | This reverts commit ba36554e02872e48d146177a57a9cfb154727fae. It turns out it reinstates bugs like this: $ perl -e 'for(1..10){for(__PACKAGE__){warn $_; $_++}}' main at -e line 1. maio at -e line 1. maip at -e line 1. maiq at -e line 1. mair at -e line 1. mais at -e line 1. mait at -e line 1. maiu at -e line 1. maiv at -e line 1. maiw at -e line 1.
* [perl #119055] Make qq with no vars read-onlyFather Chrysostomos2013-07-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | In commit 2484f8db I stopped constant folding from changing the read- onliness of expressions like 1+2, which should return mutable values, seeing that ${\1}+2 returns a mutable value. (After all, constant folding is supposed to be solely an optimisation, without changing behaviour.) This is accomplished by turning on the PADTMP flag, which tells opera- tors like \ to copy the scalar. I did not realise at the time that some qq strings like "hello\n" and qq "foo" (but not just "foo") are implemented using constant folding. The lexer outputs something like stringify("foo"), which is compiled down to a stringify op with a constant ("foo") as its only child. In this case we really do want qq"foo" to be treated as a single con- stant. That it is implemented using folding while "foo" is not is an implementation detail we should hide. So turn off the PADTMP flag when folding a stringify op.
* [perl #119043] Exempt shared hash key consts from roFather Chrysostomos2013-07-281-1/+3
| | | | | | | | | | | | Commit 19130678b4 stopped copy-on-write scalars from being exempt from readonliness in ck_svconst (called for every OP_CONST). That was for the sake of consistency. It turns out this breaks CPAN modules, so change it back, but only for shared hash key scalars, not other COW scalars. This is an historical artefact left over from when copy-on-write used the read-only flag without the scalar actually being read-only.
* [perl #119051] Fix crash with \&$glob_copyFather Chrysostomos2013-07-281-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | $ref = *Foo::nosub; \&$ref; The assignment creates a glob copy (coercible glob; one that down- grades back to a simple scalar when assigned to). \&$ref autovivifies a stub in that glob. The CvGV pointer ends up pointing to $ref, rather than *Foo::nosub. $ref can easily cease being a glob. So crashes happen. Stub autovivification used to stringify the glob, look it up again by name, and then vivify the stub in the glob. In commit 186a5ba82d584 I removed what seemed like a waste of CPU cycles, but apparently it served some purpose. The lookup caused CvGV to point to *Foo::nosub, rather than $x. This commit restores the stringfy-and-lookup if the glob is coercible (SvFAKE). It goes a little further and turns off the SvFAKE flag if the glob just looked up is also FAKE. It turns out this bug is old, and has been triggerable via glob copies in stash elements for a long time. 186a5ba82d584 made it easier to trigger the bug (so it is a regression from 5.16).
* Make overloaded constants always read-onlyFather Chrysostomos2013-07-251-1/+1
| | | | | | | They were not read-only if the constant handler returned a shared hash key scalar. This was brought up in bug #109744.
* [perl #79908] Stop sub inlining from breaking closuresFather Chrysostomos2013-07-251-54/+3
| | | | | | | | | | | | | | | | | | | | | | | | When a closure closes over a variable, it references the variable itself, as opposed to taking a snapshot of its value. This was broken by the constant optimisation added for constant.pm’s sake: { my $x; sub () { $x }; # takes a snapshot of the current value of $x } constant.pm no longer uses that mechanism, except on older perls, so we can remove this hack, causing code like this this to start work- ing again: BEGIN{ my $x = 5; *foo = sub(){$x}; $x = 6 } print foo; # now prints 6, not 5
* Make sub(){42} return a mutable valueFather Chrysostomos2013-07-251-0/+2
| | | | | | | | | | | | | | | | But only make it do so in lvalue context. This will be just as fast in true rvalue context. In either case, it is still inlined. This makes sub () { 42 } and sub () { return 42 } do the same thing. It also means that sub () { '-'x75 } reverts back to returning a muta- ble value, the way it did in 5.16. From now on, tweaks to constant folding will no longer affect the mutability of the return value of a nullary function. ‘use constant’ is unaffected. It still returns read-only values. This was brought up in ticket #109744.
* Inline list constantsFather Chrysostomos2013-07-251-0/+11
| | | | | | | | | | | These are inlined the same way as 1..5. We have two ops: rv2av | `-- const The const op returns an AV, which is stored in the op tree, and then rv2av flattens it.
* Allow stash elems to be array refsFather Chrysostomos2013-07-251-2/+35
| | | | | | | | | | | | | | | | | | These turn into CVs that return the contents of the array. Future commits will make constant.pm use these and also make them inlinable. Even without inlining, these subs are faster, because they are XSUBs: $ time ./perl -Ilib -e 'my @a=1..1000000; sub foo { @a } () = foo for 1..10' real 0m3.725s user 0m3.407s sys 0m0.227s $ time ./perl -Ilib -e 'my @a=1..1000000; BEGIN { $::{foo} = \@a } () = foo for 1..10' real 0m2.153s user 0m1.949s sys 0m0.121s
* Stop folding of ops from changing mutabilityFather Chrysostomos2013-07-251-0/+1
| | | | If $a+$b produces a mutable value, then so should 1+2.
* [perl #3105] Make 1..3 modification safeFather Chrysostomos2013-07-251-1/+7
| | | | | | | | | | | This construct is optimised at compile time to an anonymous array with an implicit @{} around it if both arguments are constant. Modifying elements of that array produces wrong results the next time the same code is executed. If we mark each element of the array as PADTMP, then it will be treated like an operator’s return value (which it is) and get copied as appropriate.
* op.c: Stop copying constants under ithreadsFather Chrysostomos2013-07-251-11/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes bugs #21979, #89188, #109746, #114838 and #115388 and mostly fixes #109744 and #105906 (other issues still remain in those two tickets). Because the PADTMP flag was doing double duty, indicating that a pad slot was in use in addition to indicating a target, constants could not be shared between pad slots, as freeing one const op (and turning of its PADTMP flag in pad_free) would mark some other pad slot as free. I believe this may have been fixed already by change 3b1c21fabed, which made const ops use pad_swipe (which removes the SV from the pad) instead of pad_free (which marks it as available for reuse). But the copying still happens. In any case, as of the previous commit, whether a pad slot for a con- stant is in use is now stored in the pad name. Slots in use for const ops now have &PL_sv_no names. So there is no longer any reason to copy the constants. The difference can be observed thus: Before: $ ./perl -lIlib -MDevel::Peek -e 'sub foo(){42} Dump foo; Dump foo' SV = IV(0x7f94ea02ef10) at 0x7f94ea02ef20 REFCNT = 2 FLAGS = (PADTMP,IOK,READONLY,pIOK) IV = 42 SV = IV(0x7f94ea02eeb0) at 0x7f94ea02eec0 REFCNT = 1 FLAGS = (PADTMP,IOK,READONLY,pIOK) IV = 42 After: $ ./perl -lIlib -MDevel::Peek -e 'sub foo(){42} Dump foo; Dump foo' SV = IV(0x7f894882ef10) at 0x7f894882ef20 REFCNT = 3 FLAGS = (IOK,READONLY,pIOK) IV = 42 SV = IV(0x7f894882ef10) at 0x7f894882ef20 REFCNT = 3 FLAGS = (IOK,READONLY,pIOK) IV = 42 Notice the different addresses. There are still special cases for copying &PL_sv_undef, which I need to tackle. Since most constants created by ‘use constant’ have the PADMY flag on (since they reside in lexical variables inside constant.pm) and PADMY and PADTMP are exclusive, I have stop turning on PADTMP for constants. It is no longer necessary now, since before its purpose was to mark pad entries as being in use. That means many to-do tests pass.
* pad.c: Use &PL_sv_no for const pad namesFather Chrysostomos2013-07-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently &PL_sv_undef as a pad name can indicate either a free slot available for use by pad_alloc or a slot used by an op target (or, under ithreads, a constant or GV). Currently pad_alloc distinguishes between free slots and unnamed slots based on whether the value in the pad has PADMY or PADTMP set. If neither is set, then the slot is free. If either is set, the slot is in use. This makes it rather difficult to distinguish between constants stored in the pad (under ithreads) and targets. The latter need to be copied when referenced, to give the impression that a new scalar is being returned by an operator each time. (So \"$a" has to return a refer- ence to a new scalar each time, but \1 should return the same one.) Also, constants are shared between recursion levels. Currently, if the value is marked READONLY or is a shared hash key scalar, it is shared. But targets can also me shared hash keys, resulting in bugs. It also makes it impossible for the same constant to be shared by mul- tiple pad slots, as freeing one const op will turn off the PADTMP flag while the other slot still uses it, making the latter appear to be free. Hence a lot of copying occurs under ithreads. (Actually, that may not be true any more since 3b1c21fabed, as freed const ops swipe their constants from the pad. But right now, a lot of copying does still happen.) Also, XS modules may want to create const ops that return the same mutable SV each time. That is currently not possible without various workarounds including custom ops and references. (See <https://rt.perl.org/rt3/Ticket/Display.html?id=105906#txn-1075354>.) This commit changes pad_alloc and pad_free to use &PL_sv_no for con- stants and updates other code to keep all tests passing. Subsequent commits will actually use that information to fix bugs. This will probably break PadWalker, but I think it is an acceptable trade-off. The alternative would be to make PadnamePV forever more complex than necessary, by giving it a special case for &PL_sv_no and having it return NULL. I gave PadnameLEN a special case for &PL_sv_undef, so it may appear that I have simply shifted the complexity around. But if pad names stop being SVs, then this exception will simply disappear, since the global &PL_padname_undef will have 0 in its length field.
* op.c:S_fold_constants: Add assertionFather Chrysostomos2013-07-251-0/+1
| | | | | | | | | | | | | | This code correctly handles a value returned by a folded constant that is a target or a mortal. If it is neither, then it takes ownership of a reference count (with- out doing SvREFCNT_inc), so it ends up sharing a reference count with whatever owned it before. That is only safe to do with immortals, which is (afaict) the only other type of scalar that can get through this code, so it is actually correct. Changes elsewhere could easily break this, though, so add an assertion.
* op.c: Add op_folded to BASEOPNiels Thykier2013-07-191-4/+10
| | | | | | | | | Add a new member, op_folded, to BASEOP. It is replacement for OPpCONST_FOLDED (which can only be set on OP_CONST). At the moment OPpCONST_FOLDED remains, as it is exposed in B (e.g. B::Concise relies on it). Signed-off-by: Niels Thykier <niels@thykier.net>
* Stop using IV in pmop; remove workaroundFather Chrysostomos2013-07-061-13/+0
| | | | | | | | | | | See ticket #118055 for all the detail. On systems where IV is bigger than a pointer, the slab allocator messes things up because it only provides pointer alignment. If pmops have an IV field, we cannot allocate them via slab on such systems. Pmops actually don’t need an IV, just a PADOFFSET. So we can change them and remove the workaround. This is obviously not suitable for maint.
* op.c: White-space onlyKarl Williamson2013-07-041-10/+10
| | | | Outdent to correspond with removed block
* PATCH: [perl #114178] di/ds/ig exempt from warnings in void contextKarl Williamson2013-07-041-14/+1
|
* Terser fix to avoid warning about an empty body for Slab_to_rw().Nicholas Clark2013-07-021-4/+3
| | | | | | | Slab_to_rw() is only defined as a function with -DPERL_DEBUG_READONLY_OPS. This approach to silencing the warning feels more robust, because it ensures that Slab_to_rw() acts as a single statement whatever compile-time options are used.
* op.c: Suppress compiler warningFather Chrysostomos2013-06-281-0/+1
| | | | | | | | | | | Sorry, commit 08aff5359 was not quite ready and I pushed it too soon. The purpose of the if block that it removed was to suppress a warn- ing about an unused variable, but it was a very strange way of accom- plishing that. We have a much simpler way that takes only one line and expresses its intent clearly.
* op.c: Remove dummy code from const_sv_xsubFather Chrysostomos2013-06-281-8/+0
| | | | | | | This was added in commit 9cbac4c7 with no explanation. It has been #ifdeffed out since it was added. That commit was supposedly just for compiler warnings. I think this was something else the author was playing with that got combined in the same patch by mistake.
* op.c:cv_ckproto_len_flags: do null checks firstFather Chrysostomos2013-06-281-2/+2
| | | | | Checking local variables for nullness is faster than calling ckWARN_d, which involves a function call.
* Reinstate UTF8fFather Chrysostomos2013-06-281-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | This format string allows char*s to be interpolated with the utf8ness and length specified as well, avoiding the need to create extra SVs: Perl_croak(aTHX_ "Couldn't twiggle the twoggle in \"%"UTF8f"\"", UTF8fARG(is_utf8, len, s)); This is the second attempt. I screwed up in commits 1c8b67b38f0a5 and b3e714770ee1 because I didn’t really understand how varargs functions receive their arguments. They are like structs, in that different members can be different sizes. So therefore both ends--the caller and the called--*must* get the casts right, or the data will be corrupted. The main mistake I made was to use %u in the format for the first argument and then retrieve it as UV (a simple typo, I meant unsigned int or U32--I don’t remember). To be on the safe side, I added a UTF8fARG macro (after SVfARG), which (unlike SVfARG) takes three arguments and casts them explicitly, mak- ing it much harder to get this wrong at call sites.
* cv_ckproto should disregard spacesPeter Martini2013-06-271-41/+50
| | | | | | | This included some refactoring to break down the original large if block into smaller, more manageable chunks, although the only functional change was to pass the two string buffers through S_strip_spaces.
* Put all sort arguments in list contextFather Chrysostomos2013-06-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The arguments following the first were using the context the enclosing function was called in. sub context { warn qw[void scalar list][wantarray + defined wantarray ] } sub foo { sort +context, context; print "------\n"; } foo; $_ = foo; [foo]; __END__ Output: list at - line 1. void at - line 1. ------ list at - line 1. scalar at - line 1. ------ list at - line 1. list at - line 1. ------ Extend the list context to all arguments.
* Put sort arguments in lvalue contextFather Chrysostomos2013-06-261-1/+7
| | | | | | | | | | | | Since $a and $b are aliased to the actual scalars being sorted, and since they can be modified, the list of items needs to be in lvalue context, like the arguments to grep. Otherwise implementation details leak through, in that sort{$a=1} $_,... will modify $_, but sort{$a=1} $#_,... will fail to modify $#_. The way I have written the loop and if() condition (the if inside the loop) may seem odd and inefficient, but the next commit will take advantage of that.
* op.c:S_simplify_sort: remove redundant OPf_STACKED checkFather Chrysostomos2013-06-251-2/+0
| | | | | S_simplify_sort is only called from one spot and only when the OPf_STACKED flag is not set.
* op.c:ck_sort: Restore HINT_LOCALIZE_HH checkFather Chrysostomos2013-06-251-1/+2
| | | | | I remove this by mistake in commit 354dd559d99. It makes no difference to the behaviour. This check is just for efficiency.
* Revert "Use UTF8f in more places"Karl Williamson2013-06-251-2/+4
| | | | | | | | This reverts commit acc19697c67fa63c10e07491b670a26c48f4175f. This and the other UTF8f patch are causing significant problems on some configurations on 32-bit platforms. We've decided to revert them until they can be resubmitted after the kinks get ironed out.
* Remove spaces from a (copy of) a proto when used. The logic that uses ↵Peter Martini2013-06-251-0/+1
| | | | prototypes assumes spaces were already gone, which may not be true if they were added via XS / set_prototype.
* perldiag: Correct ‘length() used on %s’Father Chrysostomos2013-06-231-0/+2
|
* op.c: Refactor calls to bad_type_svFather Chrysostomos2013-06-231-11/+12
| | | | | Every single caller passes gv_ename(namegv), so make it accept a GV instead and have *it* call gv_ename(namegv).
* Use UTF8f in more placesFather Chrysostomos2013-06-231-4/+2
| | | | This saves having to allocate as many SVs.
* Stop ck_index from flattening other people’s SVsFather Chrysostomos2013-06-221-1/+8
| | | | | | | | | | | | | | | | By passing to fbm_compile the SV that is the second argument to index(), ck_index causes it to be stringified. That means, for example, that dualvars will lose their numeric representation and regexps will be flattened (affecting regexp code blocks). This patch allows POK-only SVs to be compiled into BMs in place, as it just adds magic and does not otherwise affect them. Other SVs get copied first. Also, I avoided a compile-time uninitialized warning by not running fbm_compile on undef SVs.
* Stop split from mangling constantsFather Chrysostomos2013-06-221-1/+17
| | | | | | | | | | | | | | | | | | | | | | | At compile time, if split occurs on the right-hand side of an assign- ment to a list of scalars, if the limit argument is a constant con- taining the number 0 then it is modified in place to hold one more than the number of scalars. This means ‘constants’ can change their values, if they happen to be in the wrong place at the wrong time: $ ./perl -Ilib -le 'use constant NULL => 0; ($a,$b,$c) = split //, $foo, NULL; print NULL' 4 I considered checking the reference count on the SV, but since XS code could create its own const ops with weak references to the same cons- tants elsewhere, the safest way to avoid modifying someone else’s SV is to mark the split op in ck_split so we know the SV belongs to that split op alone. Also, to be on the safe side, turn off the read-only flag before modi- fying the SV, instead of relying on the special case for compile time in sv_force_normal.
* Improved struct pmop alignment fix - avoid the slow path on 64 bit systems.Nicholas Clark2013-06-211-1/+1
| | | | | | | | Commit c2a50ddb1bed6576 works round an alignment bug in the slab allocator for 32 bit systems built with 64 bit IVs. However, the C pre-processor logic meant that the test path was enabled on true 64 bit systems. It's not needed there, so improve the logic so that it isn't compiled for platforms where pointers are 64 bit.
* [perl #118047] Don’t warn for tr//a/cFather Chrysostomos2013-06-191-1/+1
| | | | | | Since /c means to invert the search list (the empty string), making it match all characters, it doesn’t make sense to warning about the replacement list (a) being longer than the search list.
* op.c: Don’t reallocate a temp for lvalue funcsFather Chrysostomos2013-06-141-3/+0
| | | | | | | | | | | | | | | There is no reason why keys, substr, pos and vec that can occur in lvalue context need to reliquish ownership of the scalar in the scratchpad used to return the value in rvalue context (the TARG) and then have a new one allocated. Also, the new TARG was marked PADMY, so, if the lvalue op got freed (e.g., if it was inside if(0){...}), then its pad slot would remain unusable by code subsequently compiled in the same sub, since pad_free only turns off the PADTMP flag, not the PADMY flag, and it would hence appear to pad_alloc to be still in use. So it would waste a small amount of memory in rare cases. (Based on reading code, not on a gdb session.)
* op.c: add assertionFather Chrysostomos2013-06-141-0/+1
|
* fix category on "Statement unlikely to be reached"Ricardo Signes2013-06-131-1/+1
| | | | | | The warning is documented as an "exec" category warning, but the implementation mixes checking for exec and syntax. This makes only the exec category apply.
* Fix crashes after syntax errors in lexical subsFather Chrysostomos2013-06-021-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Peter Martini fixed this in commit 89e006ae4e39db for our subs. (Thank you, BTW, if you are reading this.) The warning is expected; the assertion failure is not: $ ./miniperl -Ilib -Mfeature=:all -e 'state sub a { is ref } a()' The lexical_subs feature is experimental at -e line 1. Assertion failed: (hek), function Perl_ck_subr, file op.c, line 10558. Abort trap: 6 $ ./miniperl -Ilib -Mfeature=:all -e 'my sub a { is ref } a()' The lexical_subs feature is experimental at -e line 1. Assertion failed: (SvTYPE(_svmagic) >= SVt_PVMG), function S_mg_findext_flags, file mg.c, line 398. Abort trap: 6 $ The prototype CV for a my sub is stored in magic attached to the pad name. The. The code to fetch the prototype CV for a my sub calls mg_find on the pad name. If a syntax error occurs when the sub is be ing compiled, the magic will never be attached, so the pad name (pad names are currently SVs) will not have been upgraded to SVt_PVMG, causing an assertion failure in mg_find, which only accepts SVs thus upgraded. When a pad entry is created, it is automatically filled with an empty SV of the appropriate type. For a subroutine, this is a nameless CV stub. CVs can be named in two ways, via GVs for package subs, or via heks for lexical subs. This stub has neither and is truly nameless. Since a lexical sub is never installed if it contains a syntax error, this stub is visible during subsequent compilation in the same scope. ck_subr wasn’t prepared to handle a stub with absolutely no name attached to it, since it is designed for handling sub calls where the sub is known at compile time, so there must be a GV available to it, unless the sub is lexical, and all lexical subs have heks. This commit fixes the assumptions in both places. Exactly what hap- pens and what is returned is not so important, as this only hap- pens after a syntax error, when the op tree is going to be thrown away anyway.
* [perl #116735] Honour lexical prototypes when no parens are usedFather Chrysostomos2013-06-021-19/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As Peter Martini noted in ticket #116735, lexical subs produce dif- ferent op trees for ‘foo 1’ and ‘foo(1)’. foo(1) produces an rv2cv op with a padcv kid. The unparenthetical version produces just a padcv op. And the difference in op trees caused lexical sub calls to honour prototypes only in the presence of parentheses, because rv2cv_op_cv (which searches for the cv in order to check its prototype) was expecting rv2cv+padcv. Not realising there was a discrepancy between the two forms, and noticing that foo() produces *two* newCVREF ops, in commit 279d09bf893 I made newCVREF return just a padcv op for lexical subs. At the time I couldn’t figure out why there were two rv2cv ops, and punted on researching it. This is how it works for package subs: When a sub call is compiled, if there are parentheses, an implicit '&' is fed to the parser. The token that follows is a WORD token with a constant op attached to it, containing the name of the subroutine. When the parser sees '&', it calls newCVREF on the const op to create an rv2cv op. For sub calls without parentheses, the token passed to the parser is already an rv2cv op. The resulting op tree is the same either way. For lexical subs, I had the lexer emitting an rv2cv op in both paths, which was why we got the double rv2cv when newCVREF was returning an rv2cv for lexical subs. The real solution is to call newCVREF in the lexer only when there are no parentheses, since in that case the lexer is not going to call newCVREF itself. That avoids a redundant newCVREF call. Hence, we can have newCVREF always return an rv2cv op. The result is that ‘foo(1)’ and ‘foo 1’ produce identical op trees for a lexical sub. One more thing needed to change: The lexer was not looking at the lexical prototype CV but simply the stub to be autovivified, so it couldn’t see the parameter prototype attached to the CV (the stub doesn’t have one). The lexer needs to see the parameter prototype too, in order to deter- mine precedence. The logic for digging through pads to find the CV has been extracted out of rv2cv_op_cv into a separate (non-API!) routine.
* Name lexical constantsFather Chrysostomos2013-06-021-1/+4
| | | | | | | | | | | | | | | | | | $ ./perl -Ilib -Mfeature=:all -e 'my sub a(){44} a()' The lexical_subs feature is experimental at -e line 1. Assertion failed: (hek), function Perl_ck_subr, file op.c, line 10558. Abort trap: 6 The experimental warning is expected. The assertion failure is not. When a call checker is invoked, the name of the subroutine is passed to it. op.c:ck_subr gets the name from the CV’s cv (CvGV) or, in the case of lexical subs, from its name hek (CvNAME_HEK). If neither exists, ck_subr cannot cope. Lexical subs never have a GV pointer. Lexical constants were acci- dentally having neither a GV pointer nor a hek. They should have a hek, like other lexical subs.
* Ensure that the IV in struct pmop (for ithreads) is aligned properly.Nicholas Clark2013-05-241-0/+13
| | | | | | | | | | | | | | | | | | | The members of struct pmop vary between ithreads and non-ithreads builds. For ithreads, an IV is used for op_pmoffset. For 32 bit platforms built with -Duse64bitint, IVs are 64 bits, but pointers (and all other members of all OP structures) are 32 bits, hence on 32 bit platforms OP structure sizes can be an odd multiple of 4 bytes. Since the swap to the slab allocator, this is causing problems on architectures where 8 byte IVs have to be 8 byte aligned, notably sparcs. The long-term fix is to replace the IV with an appropriate 32 bit type, as it is being used for an array index. However, for maint-5.18 we need a work around which doesn't change the public headers and ideally doesn't impose a large speed or memory penalty. Hence for now, simply avoid using the slab allocator when allocating a struct pmop. Only do this for 32 bit platforms build with 8 byte IVs and ithreads. This is the interim fix for RT #118055.
* fix various podcheck nitsDavid Golden2013-05-231-2/+2
|
* Some more comments describing the slab allocator.Nicholas Clark2013-05-221-1/+16
| | | | | These are based on the description of commit 8be227ab5eaa23f2, but provide explanations near to the relevant C code.
View Lorry Controller Status