summaryrefslogtreecommitdiff
path: root/pp.c
Commit message (Collapse)AuthorAgeFilesLines
* (perl #131786) avoid a duplicate symbol error on _LIB_VERSIONTony Cook2018-03-121-8/+0
| | | | | | | | | | | | | | For -flto -mieee-fp builds, the _LIB_VERSION definition in perl.c and in libieee conflict, causing a build failure. The test we perform in Configure checks only that such a variable exists (and is declared), it doesn't check that we can *define* such a variable, which the code in pp.c tried to do. So rather than trying to define the variable, just initialize it during our normal interpreter initialization. (cherry picked from commit fa2e45943e2b6ce22cf70dba5b47afe73c8c7c80)
* (perl #131954) don't initialize mark before a possible move of the stackTony Cook2018-03-021-1/+3
| | | | (cherry picked from commit 57bd660029d94312ca4eb88993889d981f41b484)
* [perl #131627] extend stack in scalar-context pp_list when no argsAaron Crane2017-08-231-0/+1
| | | | | | | | In scalar (well, non-list) context, pp_list always yields exactly one stack element. It must therefore extend the stack for that element, in case there were no arguments on the stack when it started. (cherry picked from commit b54564c32e53d4c517e4d4810eeb633be80649a9)
* S_require_tie_mod(): use a new stackDavid Mitchell2017-08-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RT #130861 This function is used to load a module associated with various magic vars, like $[ and %+. Since it can be called 'unexpectedly', it should use a new stack. The issue in this ticket was equivalent to my $var = '['; $$var; where the symbolic dereference triggered a run-time load of arybase.pm, which grew the stack, invalidating the SP in pp_rv2sv. Note that most of the stuff which S_require_tie_mod() calls, such as load_module(), will do its own PUSHSTACK(); but S_require_tie_mod() also does a bit of stack manipulation itself. The test case includes a magic number, 125, which happens to be the exact size necessary to trigger a stack realloc in S_require_tie_mod(). In later perl versions this value may well change. But it seemed too expensive to call fresh_perl_is() 100's of times with different values of $n. This commit also adds a SPAGAIN to pp_rv2sv on the 'belt and braces' principle. This commit is based on an earlier effort by Aaron Crane. (cherry picked from commit 655f5b268af8bf50c44ba4ae4803a33c9b792b8b)
* vec(): defer lvalue out-of-range croakingDavid Mitchell2017-03-311-26/+14
| | | | | | | | | | | | | | | | | | | | | RT #131083 Recent commits v5.25.10-81-gd69c430 and v5.25.10-82-g67dd6f3 added out-of-range/overflow checks for the offset arg of vec(). However in lvalue context, these croaks now happen before the SVt_PVLV was created, rather than when its set magic was called. This means that something like sub f { $x = $_[0] } f(vec($s, -1, 8)) now croaks even though the out-of-range value never ended up getting used in lvalue context. This commit fixes things by, in pp_vec(), rather than croaking, just set flag bits in LvFLAGS() to indicate that the offset is -Ve / out-of-range. Then in Perl_magic_getvec(), return 0 if these flags are set, and in Perl_magic_setvec() croak with a suitable error.
* Perl_do_vecget(): change offset arg to STRLEN typeDavid Mitchell2017-03-171-2/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | ... and fix up its caller, pp_vec(). This is part of a fix for RT #130915. pp_vec() is responsible for extracting out the offset and size from SVs on the stack, and then calling do_vecget() with those values. (Sometimes the call is done indirectly by storing the offset in the LvTARGOFF() field of a SVt_PVLV, then later Perl_magic_getvec() passes the LvTARGOFF() value to do_vecget().) Now SvCUR, SvLEN and LvTARGOFF are all of type STRLEN (a.k.a Size_t), while the offset arg of do_vecget() is of type SSize_t (i.e. there's a signed/unsigned mismatch). It makes more sense to make the arg of type STRLEN. So that is what this commit does. At the same time this commit fixes up pp_vec() to handle all the possibilities where the offset value can't fit into a STRLEN, returning 0 or croaking accordingly, so that do_vecget() is never called with a truncated or wrapped offset. The next commit will fix up the internals of do_vecget() and do_vecset(), which have to worry about offset*(2^n) wrapping or being > SvCUR(). This commit is based on an earlier proposed fix by Aaron Crane.
* RT#130624: heap-use-after-free in 4-arg substrAaron Crane2017-02-271-1/+3
|
* Show sub name in signature arity-check error messagesAaron Crane2017-02-181-6/+27
|
* Moving variables to their innermost scope.Andy Lester2017-02-181-6/+5
| | | | | | Some vars have been tagged as const because they do not change in their new scopes. In pp_reverse in pp.c, I32 tmp is only used to hold a char, so is changed to char.
* fix ord of upgraded empty stringZefram2017-01-271-1/+1
| | | | | | pp_ord fell foul of the new API stricture added by d1f8d421df731c77beff3db92d27dc6ec28589f2. Change it to avoid calling utf8n_to_uvchr() on an empty string. Fixes [perl #130545].
* (perl #130262) split scalar context stack overflow fixTony Cook2017-01-161-1/+1
| | | | | pp_split didn't ensure there was space for its return value in scalar context.
* In A && B, stop special-casing boolean-ness of ADavid Mitchell2017-01-061-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some ops, (currently PADHV and RV2HV) can be flagged as being in boolean context, and if so, may return a simple truth value which may be more efficient to calculate than a full scalar value. (This was originally motivated by code like if (%h) {...}, where the scalar context %h returned a bucket ratio string, which involved counting how many HvARRAY buckets were non-empty, which was slow in large hashes. It's been made less important since %h in scalar context now just returns a key count, which is quick to calculate.) There is an issue with the A argument of A||B, A//B and A&&B, in that, although A checked by the logop in boolean context, depending on its truth value the original A may be passed through to the next op. So in something like $x = (%h || -1), it's not sufficient for %h to return a truth value; it must return a full scalar value which may get assigned to $x. So in general, we only mark the A op as being in boolean context if the logop is in void context, or if the returned A would only be consumed in boolean context; so !(A||B) would be ok for example. However, && is a special case of this, since it will return the original A only if A was false. Before this commit, && was special-cased to mark A as being in boolean context regardless of the context of (A&&B). The downside of this is that the A op can't just return &PL_sv_no as a false value; it has to return something that is usable in scalar context too. For example with %h, it returns sv_2mortal(newSViv(0))), which stringifies to "0" while &PL_sv_no stringifies to "". This commit removes that special case and makes && behave like || and // again. The upside is that some ops in boolean context will be able to more cheaply return a false value (e.g. just &PL_sv_no verses sv_2mortal(newSViv(0))). The main downside is that && in unknown context (typically an 'if (%h} {...}' as the last statement in a sub) will have to check at runtime whether the caller context is slower. It will also have to return a scalar value for something like $y = (%h && $x), but that's a relatively uncommon occurrence, and now that %h in scalar context doesn't have to count used buckets, the extra cost in these rare cases is minor.
* re-implement boolean context detectionDavid Mitchell2017-01-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When certain ops are used in a boolean context (currently just PADHV and RV2SV, implementing '%hash'), one of the private flags OPpTRUEBOOL or OPpMAYBE_TRUEBOOL is set on the op to indicate this; at runtime, the pp function can then just return a boolean value rather than a full scalar value (in the case of %hash, an element count). However, the code which sets these flags has had a complex history, and is a bit messy. It also sets the flags incorrectly (but safely) in many cases: principally indicating boolean context when it's in fact void, or scalar context when it's in fact boolean. Both these permutations make the code potentially slower (but still correct). [ As a side-note: in 5.25, a bare %hash in scalar context changed from returning a bucket count etc, to just returning a key count, which is quicker to calculate. So the boolean optimisation for %hash is not nearly as important now: it's now just the overhead of creating a temp to return a count verses returning &PL_sv_yes, rather than counting keys. However the improved and generalised boolean context detection added by this commit will be useful in future to apply boolean context to other ops. ] In particular, this wasn't being optimised (i.e. a 'not' of a hash within an if): if (!%hash) { ...} This commit fixes all these cases (and uncomments a load of failing tests in t/perf/optree.t which were added in the previous commit.) It makes the code below nearly 3 times faster: my $c; my %h = 1..10; for my $i (1..10_000_000) { if (!%h) { $c++ }; } It restructures the relevant code in rpeep() so that rather than switching on logops like OP_OR, then seeing if that op is preceded by PADHV/RV2HV, it instead switches on PADHV/RV2HV then sees if succeeding ops impose boolean context on that op - that is to say, in all possible execution paths after the PADHV/RV2HV pushes a scalar onto the stack, will that scalar only ever be used for a boolean test? (*). The scanning of succeeding ops is extracted out into a static function. This will make it very easy in future to apply boolean context to other ops too, or to expand the definition of boolean context (e.g. adding 'xor'). (*) Although in theory an expression like (A && B) can return A if A is false, if A happens to be %hash, and as long as pp_padhv() etc return a boolean false value that is also usable in scalar context (so it returns 0 rather than PL_sv_no), then we can pretend that OP_AND's LH arg is never used as a scalar.
* split ' ', $foo: don't check end byteDavid Mitchell2016-12-261-3/+3
| | | | | | | | The special-cased code to skip spaces at the start of the string didn't check that s < strend, so relied on the string being \0-terminated to work correctly. The introduction of the isSPACE_utf8_safe() macro showed up this dodgy assumption by causing assert failures in regen.t under LC_ALL=en_US.UTF-8 PERL_UNICODE="".
* Convert core to use toFOO_utf8_safe()Karl Williamson2016-12-231-9/+9
|
* Convert some calls to test for malformationsKarl Williamson2016-12-231-1/+1
| | | | | | | | | | | | | | Code review showed several places in core where a UTF-8 sequence that was for a code point below 256 could be malformed, and be blindly accepted. Convert these to use the similar macro that does the check. One place in regexec.c was not converted because it is working on the pattern, which perl should have generated itself, so very unlikely to be bemalformed. I didn't add tests for these, as it would be a pain to figure out somehow to trigger them, and this is precautionary, based on code reading rather than any known field experience.
* For character case changing, create macros and useKarl Williamson2016-12-231-9/+9
| | | | | This creates several macros that future commits will use to provide a layer between the caller and the function.
* Convert core (except toke.c) to use isFOO_utf8_safe()Karl Williamson2016-12-231-4/+4
| | | | | | | The previous commit added this feature; now this commit uses it in core. toke.c is deferred to the next commit to aid in possible future bisecting, because some of the changes there seem somewhat more likely to expose bugs.
* split was leaving PL_sv_undef in unused ary slotsDavid Mitchell2016-11-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This: @a = split(/-/,"-"); $a[1] = undef; $a[0] = 0; was giving Modification of a read-only value attempted at foo line 3. This is because: 1) unused slots in AvARRAY between AvFILL and AvMAX should always be null; av_clear(), av_extend() etc do this; while av_store(), if storing to a slot N somewhere between AvFILL and AvMAX, doesn't bother to clear between (AvFILL+1)..(N-1) on the assumption that everyone else plays nicely. 2) pp_split() when splitting directly to an array, sometimes over-splits and has to null out the excess elements; 3) Since perl 5.19.4, unused AV slots are now marked with NULL rather than &PL_sv_undef; 4) pp_split was still using &PL_sv_undef; The fault was with (4), and is easily fixed.
* add sv_set_undef() API functionDavid Mitchell2016-11-241-1/+1
| | | | | | | This function is equivalent to sv_setsv(sv, &PL_sv_undef), but more efficient. Also change the obvious places in the core to use the new idiom.
* Change white space to avoid C++ deprecation warningKarl Williamson2016-11-181-5/+5
| | | | | | | | | | | | | | | | | | | | | | C++11 requires space between the end of a string literal and a macro, so that a feature can unambiguously be added to the language. Starting in g++ 6.2, the compiler emits a warning when there isn't a space (presumably so that future versions can support C++11). Unfortunately there are many such instances in the perl core. This commit fixes those, including those in ext/, but individual commits will be used for the other modules, those in dist/ and cpan/. This commit also inserts space at the end of a macro before a string literal, even though that is not deprecated, and removes useless "" literals following a macro (instead of inserting a blank). The result is easier to read, making the macro stand out, and be clearer as to the intention. Code and modules included with the Perl core need to be compilable using C++. This is so that perl can be embedded in C++ programs. (Actually, only the hdr files need to be so compilable, but it would be hard to test that just the hdrs are compilable.) So we need to accommodate changes to the C++ language.
* pp.c: use new SvPVCLEAR and constant string friendly macrosYves Orton2016-10-191-14/+13
|
* Better optimise my/local @a = split()David Mitchell2016-10-041-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are currently two optimisations for when the results of a split are assigned to an array. For the first, @array = split(...); the aassign and padav/rv2av are optimised away, and pp_split() directly assigns to the array attached to the split op (via op_pmtargetoff or op_pmtargetgv). For the second, my @array = split(...); local @array = split(...); @{$expr} = split(...); The aassign is optimised away, but the padav/rv2av is kept as an additional arg to split. pp_split itself then uses the first arg popped off the stack as the array (This was introduced by FC with v5.21.4-409-gef7999f). This commit moves these two: my @array = split(...); local @array = split(...); from the second case to the first case, by simply setting OPpLVAL_INTRO on the OP_SPLIT, and making pp_split() do SAVECLEARSV() or save_ary() as appropriate. This makes my @a = split(...) a few percent faster.
* make OP_SPLIT a PMOP, and eliminate OP_PUSHREDavid Mitchell2016-10-041-21/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most ops that execute a regex, such as match and subst, are of type PMOP. A PMOP allows the actual regex to be attached directly to that op, due to its extra fields. OP_SPLIT is different; it is just a plain LISTOP, but it always has an OP_PUSHRE as its first child, which *is* a PMOP and which has the regex attached. At runtime, pp_pushre()'s only job is to push itself (i.e. the current PL_op) onto the stack. Later pp_split() pops this to get access to the regex it wants to execute. This is a bit unpleasant, because we're pushing an OP* onto the stack, which is supposed to be an array of SV*'s. As a bit of a hack, on DEBUGGING builds we push a PVLV with the PL_op address embedded instead, but this still isn't very satisfactory. Now that regexes are first-class SVs, we could push a REGEXP onto the stack rather than PL_op. However, there is an optimisation of @array = split which eliminates the assign and embeds the array's GV/padix directly in the PUSHRE op. So split still needs access to that op. But the pushre op will always be splitop->op_first anyway, so one possibility is to just skip executing the pushre altogether, and make pp_split just directly access op_first instead to get the regex and @array info. But if we're doing that, then why not just go the full hog and make OP_SPLIT into a PMOP, and eliminate the OP_PUSHRE op entirely: with the data that was spread across the two ops now combined into just the one split op. That is exactly what this commit does. For a simple compile-time pattern like split(/foo/, $s, 1), the optree looks like: before: <@> split[t2] lK </> pushre(/"foo"/) s/RTIME <0> padsv[$s:1,2] s <$> const(IV 1) s after: </> split(/"foo"/)[t2] lK/RTIME <0> padsv[$s:1,2] s <$> const[IV 1] s while for a run-time expression like split(/$pat/, $s, 1), before: <@> split[t3] lK </> pushre() sK/RTIME <|> regcomp(other->8) sK <0> padsv[$pat:2,3] s <0> padsv[$s:1,3] s <$> const(IV 1)s after: </> split()[t3] lK/RTIME <|> regcomp(other->8) sK <0> padsv[$pat:2,3] s <0> padsv[$s:1,3] s <$> const[IV 1] s This makes the code faster and simpler. At the same time, two new private flags have been added for OP_SPLIT - OPpSPLIT_ASSIGN and OPpSPLIT_LEX - which make it explicit that the assign op has been optimised away, and if so, whether the array is lexical. Also, deparsing of split has been improved, to the extent that perl TEST -deparse op/split.t now passes. Also, a couple of panic messages in pp_split() have been replaced with asserts().
* vax-netbsd: avoid NV_INF/NV_NAN usesJarkko Hietaniemi2016-09-301-0/+4
|
* OP_AVHVSWITCH: make op_private bits 0..1 symbolicDavid Mitchell2016-09-271-1/+1
| | | | | Add OPpAVHVSWITCH_MASK and make Concise etc display the offset as /offset=2 rather than /2.
* [perl #129164] Crash with spliceFather Chrysostomos2016-09-111-0/+4
| | | | | | | | This fixes #129166 and #129167 as well. splice needs to take into account that arrays can hold NULLs and return &PL_sv_undef in those cases where it would have returned a NULL element.
* Take advantage of SvGROW's return valueKarl Williamson2016-08-171-10/+5
| | | | | | | | I had not realized that SvGROW returned the new string pointer. Using that makes a one-step process from a two-step process. I examined the code for other possible occurrences, and found others where it seemed that the two-step seemed clearer, so left those alone.
* Remove dead code in pp.c:pp_indexFather Chrysostomos2016-08-171-10/+3
| | | | | | | | | | | | | | | | 8df0e7a28b changed /* One needs to be upgraded. */ if (little_utf8) { to /* One needs to be upgraded. */ if (little_utf8 && !IN_ENCODING) { The ‘else’ branch of that ‘if’ has some code conditional on little_utf8 being true, which could only happen before in the case of PL_encoding being set, and which cannot happen any more.
* pessimise pp_argelem, pp_argdefelemDavid Mitchell2016-08-031-61/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | These two ops assumed that, since they occur at the start of a function, weird tricks with goto and closures can't be used to cause the new lexical vars to already have a value, so the assign code can be simpler and quicker than that found in pp_sassign and pp_aassign. However Father Chrysostomos demonstrated that this wasn't the case, using e.g. code that does strange things in signature default expressions. In particular we can not assume: * that scalar lexicals will be undef * that array and hash lexicals will be empty * that lexicals and @_ can't be magical or tied; * that @_ remains unchanged (especially in relation to its number of elements) * that there are no common elements, since with aliases and closures, my @a = @_ can be equivalent to my @a = (...); @a = ($a_[0],...) So this commit removes the short-cuts, and for aggregates, if the new lexical array or hash may be non-empty, makes a copy of each @_ element first. It is intended in the near future that normal runs of OP_ARGELEM will be replaced by OP_SIGNATURE, which will be able to do a better job of knowing when its safe to optimise.
* signatures: make param and optional param count IVDavid Mitchell2016-08-031-10/+16
| | | | | | | | | During the course of parsing end exection, these values get stored as ints and UVs, then used as SSize_t. Standardise on IVs instead. Technically they can never be negative, but their final use is as indices into AVs, which is SSize_t, so it's easier to standardise on a signed value throughout.
* ucfirst() new signature diagnostic messagesDavid Mitchell2016-08-031-0/+2
| | | | | | | | | | | | | e.g. a slurpy parameter may not have a default value => A slurpy parameter may not have a default value Also, split the "Too %s arguments for subroutine" diagnostic into separate "too few" and "too many" entries in perldiag. Based on suggestions by Father Chrysostomos.
* add OP_ARGELEM, OP_ARGDEFELEM, OP_ARGCHECK opsDavid Mitchell2016-08-031-0/+206
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently subroutine signature parsing emits many small discrete ops to implement arg handling. This commit replaces them with a couple of ops per signature element, plus an initial signature check op. These new ops are added to the OP tree during parsing, so will be visible to hooks called up to and including peephole optimisation. It is intended soon that the peephole optimiser will take these per-element ops, and replace them with a single OP_SIGNATURE op which handles the whole signature in a single go. So normally these ops wont actually get executed much. But adding these intermediate-level ops gives three advantages: 1) it allows the parser to efficiently generate subtrees containing individual signature elements, which can't be done if only OP_SIGNATURE or discrete ops are available; 2) prior to optimisation, it provides a simple and straightforward representation of the signature; 3) hooks can mess with the signature OP subtree in ways that make it no longer possible to optimise into an OP_SIGNATURE, but which can still be executed, deparsed etc (if less efficiently). This code: use feature "signatures"; sub f($a, $, $b = 1, @c) {$a} under 'perl -MO=Concise,f' now gives: d <1> leavesub[1 ref] K/REFC,1 ->(end) - <@> lineseq KP ->d 1 <;> nextstate(main 84 foo:6) v:%,469762048 ->2 2 <+> argcheck(3,1,@) v ->3 3 <;> nextstate(main 81 foo:6) v:%,469762048 ->4 4 <+> argelem(0)[$a:81,84] v/SV ->5 5 <;> nextstate(main 82 foo:6) v:%,469762048 ->6 8 <+> argelem(2)[$b:82,84] vKS/SV ->9 6 <|> argdefelem(other->7)[2] sK ->8 7 <$> const(IV 1) s ->8 9 <;> nextstate(main 83 foo:6) v:%,469762048 ->a a <+> argelem(3)[@c:83,84] v/AV ->b - <;> ex-nextstate(main 84 foo:6) v:%,469762048 ->b b <;> nextstate(main 84 foo:6) v:%,469762048 ->c c <0> padsv[$a:81,84] s ->d The argcheck(3,1,@) op knows the number of positional params (3), the number of optional params (1), and whether it has an array / hash slurpy element at the end. This op is responsible for checking that @_ contains the right number of args. A simple argelem(0)[$a] op does the equivalent of 'my $a = $_[0]'. Similarly, argelem(3)[@c] is equivalent to 'my @c = @_[3..$#_]'. If it has a child, it gets its arg from the stack rather than using $_[N]. Currently the only used child is the logop argdefelem. argdefelem(other->7)[2] is equivalent to '@_ > 2 ? $_[2] : other'. [ These ops currently assume that the lexical var being introduced is undef/empty and non-magival etc. This is an incorrect assumption and is fixed in a few commits' time ]
* unimplemented_op does not implement pp_mapstartFather Chrysostomos2016-07-281-1/+1
|
* Remove IN_ENCODING macro, and all code dependent on itFather Chrysostomos2016-07-131-48/+2
|
* add missing dVAR in pp_avhvswitchDavid Mitchell2016-05-251-1/+1
| | | | make it build under -DPERL_GLOBAL_STRUCT.
* Allow assignment to &CORE::keys()Father Chrysostomos2016-05-201-2/+2
|
* Allow &CORE::foo() with array functionsFather Chrysostomos2016-05-201-7/+35
|
* Allow &CORE::foo() with hash functionsFather Chrysostomos2016-05-201-5/+16
| | | | | &CORE::keys does not yet work as an lvalue. (I’m not sure how to make that work.)
* Add avhvswitch opFather Chrysostomos2016-05-201-0/+6
| | | | | &CORE::keys() et al. will use this to switch between keys and akeys depending on the argument type.
* pp.c: Use PL_op_desc in pp_coreargsFather Chrysostomos2016-05-201-1/+1
| | | | | | | | OP_DESC is inconvienient here, because it expects an op, not an op number, so we have to follow pointers to find an appropriate op. It is also needlessly expensive, since we do not need to check for custom ops in pp_coreargs (which OP_DESC does). Just access the underlying array directly.
* [perl #128187] Forbid keys @_ in assigned lv subFather Chrysostomos2016-05-201-0/+9
| | | | | This is a continuation of this commit’s great grandparent, extending the error to arrays.
* Correct error msg for sub:lvalue{%h{k}} in sassignFather Chrysostomos2016-05-201-1/+2
| | | | | | | | | | This: sub foo : lvalue { %hash{'key'} } foo = 3; was incorrectly giving ‘Can't modify key/value hash slice in list assignment’. There is no list assignment there.
* Fix crash with: undef *_; shift;Father Chrysostomos2016-05-171-1/+1
| | | | | | | | Commit v5.13.0-149-g538f575 added on optimisation to shift() that makes pp_shift fetch @_ directly, instead of having two separate ops. Unfortunately, it used the wrong macro, namely GvAV, instead of GvAVn. The latter makes sure the array actually exists.
* Remove some autoderef leftoversFather Chrysostomos2016-05-171-34/+4
|
* better glibc i_modulo bug handlingjimc2016-05-171-52/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pp-i-modulo code currently detects a glibc bug at runtime, at the 1st exec of each I_MODULO op. This is suboptimal; the bug should be detectable early, and PL_ppaddr[I_MODULO] updated just once, before any optrees are built. Then, because we avoid the need to fixup I_MODULO ops in already built optrees, we can drop the !PERL_DEBUG_READONLY_OPS limitation on the alternative/workaround I_MODULO implementation that avoids the bug. perl.c: bug detection code is copied from PP(i_modulo), into S_fixup_platform_bugs(), and called from perl_construct(). It patches Perl_pp_i_modulo_1() into PL_ppaddr[I_MODULO] when needed. pp.c: PP(i_modulo_0), the original implementation, is renamed to PP(i_modulo) PP(i_modulo_1), the bug-fix workaround, is renamed _glibc_bugfix it is #ifdefd as before, but dropping !PERL_DEBUG_READONLY_OPS PP(i_modulo) - the 1st-exec switcher code, is dropped ocode.pl: Two i_modulo entries are added to @raw_alias. - 1st alias: Perl_pp_i_modulo => 'i_modulo' - 2nd alt: Perl_pp_i_modulo_glibc_bugfix => 'i_modulo' 1st is a restatement of the default alias/mapping that would be created without the line. 2nd line is then seen as alternative to the explicit mapping set by 1st. Alternative functions are written to pp_proto.h after the standard Perl_pp_* list, and include #if-cond, #endif wrappings, as was specified by 2nd @raw_alias addition. Changes tested by inserting '1 ||' into the 3 ifdefs and bug-detection code. TODO: In pp_proto.h generation, the #ifdef wrapping code which handles the alternative functions looks like it should also be used for the non-alternate functions. In particular, there are a handful of pp-function prototypes that should be wrapped with #ifdef HAS_SOCKET. That said, there have been no problem reports, so I left it alone. TonyC: make S_fixup_platform_bugs static, porting/libperl.t was failing.
* stop lc() etc accidentally modifying in-place.David Mitchell2016-03-241-11/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As an optimisation, [ul]c() and [ul]cfirst() sometimes modify their argument in-place rather than returning a modified copy. This should only be done when there is no possibility that the arg is going to be reused. However, this fails: use List::Util qw{ first }; my %hash = ( ASD => 1, ZXC => 2, QWE => 3, TYU => 4); print first { lc $_ eq 'qwe' } keys %hash; which prints "qwe" rather than "QWE". Bascally everything in perl that sets $_ or $a/$b and calls a code block or function, such as map, grep, for and, sort, either copies any PADTMPs, turns off SvTEMP, and/or bumps the reference count. List::Util doesn't do this, and it is likely that other CPAN modules which do "set $_ and call a block" don't either. This has been failing since 5.20.0: perl has been in-placing if the arg is (SvTEMP && RC==1 && !mg) (due to v5.19.7-112-g5cd5e2d). Make the optimisation critera stricter by always copying SvTEMPs. It still allows the optimisation if the arg is a PADTMP - I don't know whether this is unsafe too. Perhaps we can think of something better after 5.24?
* Cast away Solaris Studio 12.3 warning.Jarkko Hietaniemi2016-02-041-1/+1
| | | | "pp.c", line 3220: warning: initializer will be sign-extended: -2147483648
* make gimme consistently U8David Mitchell2016-02-031-8/+8
| | | | | | | | | | | | | The value of gimme stored in the context stack is U8. Make all other uses in the main core consistent with this. My primary motivation on this was that the new function cx_pushblock(), which I gave a 'U8 gimme' parameter, was generating warnings where callers were passing I32 gimme vars to it. Rather than play whack-a-mole, it seemed simpler to just uniformly use U8 everywhere. Porting/bench.pl shows a consistent reduction of about 2 instructions on the loop and sub benchmarks, so this change isn't harming performance.
* convert CX_PUSHSUB/POPSUB to inline fnsDavid Mitchell2016-02-031-1/+1
| | | | | | Replace CX_PUSHSUB() with cx_pushsub() etc. No functional changes.
View Lorry Controller Status