summaryrefslogtreecommitdiff
path: root/pp.c
Commit message (Collapse)AuthorAgeFilesLines
* *glob{FILEHANDLE} is no longer deprecatedRicardo Signes2016-01-021-2/+0
| | | | | | | | | We are now trying to use deprecation warnings only when we believe that a behavior will really be removed or made an error. Since we don't plan to do that with *glob{FILEHANDLE}, the warning is not useful and may be harmful. See discussion at [perl #127060].
* Deprecate wide chars in logical string opsKarl Williamson2015-12-161-0/+2
| | | | | | | See thread starting at http://nntp.perl.org/group/perl.perl5.porters/227698 Ricardo Signes provided the perldelta and perldiag text.
* infnan: NaN payload for mixed endian double-doublesJarkko Hietaniemi2015-12-141-2/+2
|
* pp_padav, pp_padhv whitespace onlyDavid Mitchell2015-12-141-16/+22
| | | | There was some bizarre indentation (1,2 or 3-space indents)
* [perl #126193] don't use a trash SV if no indexes are provided to pp_lsliceTony Cook2015-11-171-9/+14
|
* split pp_postdec() from pp_postinc() and improveDavid Mitchell2015-11-101-17/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pp_postinc() handles both $x++ and $x-- (and the integer variants pp_i_postinc/dec). Split it into two separate functions, as handling both inc and dec in the same function requires 3 extra conditionals. At the same time make the code more efficient. As currently written it: 1) checked for "bad" SVs (such as read-only) and croaked; 2) did a sv_setsv(TARG, TOPs) to return a copy of the original value; 2) checked for a IOK-only SV and if so, directly incremented the IVX slot; 3) else called out to sv_inc/dec() to handle the more complex cases. This commit combines the checks in (1) and (3) into one single big check of flags, and for the simple integer case, skips 2) and does a more efficient SETi() instead. For the non-simple case, both pp_postinc() and pp_postdec() now call a common static function to handle everything else. Porting/bench.pl shows the following raw numbers for '$y = $x++' ($x and $y lexical and holding integers): before after ------ ----- Ir 306.0 223.0 Dr 106.0 82.0 Dw 51.0 44.0 COND 48.0 33.0 IND 8.0 6.0 COND_m 1.9 0.0 IND_m 4.0 4.0
* faster add, subtract, multiplyDavid Mitchell2015-11-101-9/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In pp_add, pp_subtract and pp_multiply, special-case the following: * both args IV, neither arg large enough to under/overflow * both args NV. Starting in 5.8.0, the implementation of the arithmetic pp functions became a lot more complex (and famously, much slower), due to the need to support 64-bit integers. For example, formerly pp_add just converted both its args to an NV and returned an NV. On 64-bit systems, that could gave bad results if the mantissa of an NV was < 64 bits; for example: $ perl561 -e'$x = 0x1000000000000000; printf "%x\n", $x+1' 1000000000000000 $ perl580 -e'$x = 0x1000000000000000; printf "%x\n", $x+1' 1000000000000001 This led to a lot of complex code that covered all the possibilities of overflow etc. This commit adds some special casing to these three common arithmetic ops. It does some quick checks (mainly involving fast boolean and bit ops) to determine if both args are valid IVs (and not UVs), are not magic, and aren't very big (+ve or -ve). In this case, the result is simply SvIVX(svl) + SvIVX(svr) (or - or *) with no possibility of overflow. Failing that, if both args are NV's and not magic, then if both NVs can be converted to IVs without loss, handle as for the IV case; failing that, just return SvNVX(svl) + SvNVX(svr); For all other cases, such as mixed IV and NV or PV, fall back to the old code. On my platform (x86_64), it (along with the previous commit) reduces the execution time of the nbody benchmark (lots of floating-point vector arithmetic) by a third and in fact makes it 10% faster than 5.6.1.
* perl #126396 IRIX longdouble infinity issuesJarkko Hietaniemi2015-10-191-0/+10
| | | | | | | | | | | | | | | | | | | In IRIX longdouble (which uses the double-double format, bigendian) multiplying with infinity introduces garbage bytes to the second double of the double-double. This garbage, in turn, seems to tickle another bug in long doubles, in comparing infinities, where these garbage bytes errorneously matter when they should not. Workaround: zero these garbage bytes in multiplication. The garbage bytes seem to appear only the multiplication, as far as t/op/infnan.t can detect. Even though we could place the multiplication result to a temporary NV variable (for easier infiniteness inspection) for all the platforms and depend on optimizer doing away with the temporary, let's be conservative.
* optimise save/restore of PL_delaymagic.David Mitchell2015-10-181-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | A few places (pp_push, pp_unshift, pp_aassign) have to set PL_delaymagic on entry, and restore it on exit. These are hot pieces of code. Rather than using ENTER/SAVEI16(PL_delaymagic)/LEAVE, add an extra field to the jumpenv struct, and make the JUMPENV_PUSH / POP macros automatically save and restore this var. This means that pp_push etc only need to do a local save: U16 old_delaymagic = PL_delaymagic; PL_delaymagic = DM_DELAY; .... PL_delaymagic = old_delaymagic; and in case of an exception being raised, PL_delaymagic still gets restored. This transfers the cost of saving PL_delaymagic from each call to pp_aassign etc to each time a new run level is invoked. The latter should be much less frequent. Note that prior to this commit, pp_aassign wasn't actually saving and restoring PL_delaymagic; it was just setting it to 0 at the end. So this commit also makes pp_aassign safe against PL_delaymagic re-entrancy like pp_push and pp_unshift already were.
* Delay @ISA magic while unshiftingDagfinn Ilmari Mannsåker2015-10-181-2/+9
| | | | | | | | | | | | | | | | | pp_unshift() first calls av_unshift(), which prepends the the requisite number of undefs, then calls av_store() for each item. However, unlike pp_push() it was not setting PL_delaymagic around the av_store() loop, so when unshifting onto @ISA, its magic would be triggered while there were still undefs in the array, causig the following spurious warning: $ perl -wE 'package Foo; unshift @ISA, qw(A B)' Use of uninitialized value in unshift at -e line 1. Also fix pp_push() to save and restore PL_delaymagic instead of clearing it, so that e.g. unshifting a tied value with FETCH pushing onto another @ISA doesn't erroneously clear the value from underneath the unshift.
* Future-proof pp_trans against a possible future undefined behaviourVincent Pit2015-10-051-1/+2
| | | | | | If do_trans() ever wants to modify the stack in the future, this would cause an undefined behaviour as mPUSHi() invokes its parameter on the same argument list as PUSHmortal, which itself touches the stack.
* fix up EXTEND() callersDavid Mitchell2015-10-021-13/+16
| | | | | | | | | | | | | | | | | | | | | | The previous commit made it clear that the N argument to EXTEND() is supposed to be signed, in particular SSize_t, and now typically triggers compiler warnings where this isn't the case. This commit fixes the various places in core that passed the wrong sort of N to EXTEND(). The fixes are in three broad categories. First, where sensible, I've changed the relevant var to be SSize_t. Second, where its expected that N could never be large enough to wrap, I've just added an assert and a cast. Finally, I've added extra code to detect whether the cast could wrap/truncate, and if so set N to -1, which will trigger a panic in stack_grow(). This also fixes [perl #125937] 'x' operator on list causes segfault with possible stack corruption
* pp.c:pp_reverse: Don’t use find_rundefsvFather Chrysostomos2015-09-291-1/+1
| | | | It just calls DEFSV now, so use DEFSV directly.
* In pp.c:pp_coreargs, use DEFSV directlyFather Chrysostomos2015-09-291-4/+1
| | | | | rundefsv2 is only necessary for lexical $_. It’s slower than a simple DEFSV, which is what it falls back to anyway.
* Add macro for converting Latin1 to UTF-8, and use itKarl Williamson2015-09-041-1/+1
| | | | | | | | | This adds a macro that converts a code point in the ASCII 128-255 range to UTF-8, and changes existing code to use it when the range is known to be restricted to this one, rather than the previous macro which accepted a wider range (any code point representable by 2 bytes), but had an extra test on EBCDIC platforms, hence was larger than necessary and slightly slower.
* Change to use UVCHR_SKIP over UNI_SKIPKarl Williamson2015-09-041-2/+2
| | | | | | | | | | UNI_SKIP is somewhat ambiguous. Perl has long used 'uvchr' as part of a name to mean the unsigned values using the native character set plus Unicode values for those above 255. This also changes two calls (one in dquote_static.c and one in dquote_inline.h) to use UVCHR_SKIP; they should not have been OFFUNI, as they are dealing with native values.
* pp.c: White-space onlyKarl Williamson2015-09-031-1/+2
| | | | Make it easier to grok what comprises the 'if'
* Safefree(NULL) reductionDaniel Dragan2015-08-031-15/+16
| | | | | | | | | | | | | | | | locale.c: - the pointers are always null at this point, see http://www.nntp.perl.org/group/perl.perl5.porters/2015/07/msg229533.html pp.c: - reduce scope of temp_buffer and svrecode, into an inner branch - in some permutations, either temp_buffer is never set to non-null, or svrecode, in permutations where it is known that the var hasn't been set yet, skip the freeing calls at the end, this doesn't eliminate all permutations with NULL being passed to Safefree and SvREFCNT_dec, but only some of them regcomp.c - dont create a save stack entry to call Safefree(NULL), see ticket for this patch for some profiling stats
* pp.c: Fix typo in commentKarl Williamson2015-08-011-1/+1
|
* uc(sharp s) is itself in very early Unicode versionsKarl Williamson2015-07-281-0/+4
|
* There are no folds to multiple chars in early Unicode versionsKarl Williamson2015-07-281-0/+6
| | | | | Several places require special handling because of this, notably for the lowercase Sharp S, but not in Unicodes before 3.0.1
* Delete experimental autoderef featureAaron Crane2015-07-131-42/+1
|
* Left overshift of negatives under use integer was still wrong.Jarkko Hietaniemi2015-07-031-1/+1
| | | | | Follow-up on b3498293: the -1 stuckiness on overshift should apply only on right shift, not left shift (which should return zero).
* Define left/right shift by negative to mean the reverse shiftJarkko Hietaniemi2015-06-281-8/+35
| | | | | | | | | | | | | | Coverity CIDs 104765 and 104766 While at it, also define shifting by more than wordsize in bits to be zero, except that undef 'use integer' (use IVs) right overshift for negative shiftees means -1. (This is another corner where C leaves things undefined. A common behavior is "shift by modulo worbits", so that e.g. 1 >> 64 == 1 >> (64 % 64) == 1 >> 0, but this is completely accidental.) (Coverity didn't flag this, harder to detect statically.) Discussion thread at http://www.nntp.perl.org/group/perl.perl5.porters/2015/06/msg228842.html
* assert(arg) before derefing it since it can be NULL.Jarkko Hietaniemi2015-06-261-7/+10
| | | | Coverity CID 104813.
* assert(key) before it is derefed.Jarkko Hietaniemi2015-06-261-1/+4
| | | | Coverity CID 104855.
* Replace common Emacs file-local variables with dir-localsDagfinn Ilmari Mannsåker2015-03-221-6/+0
| | | | | | | | | | | | | | | | An empty cpan/.dir-locals.el stops Emacs using the core defaults for code imported from CPAN. Committer's work: To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed to be incremented in many files, including throughout dist/PathTools. perldelta entry for module updates. Add two Emacs control files to MANIFEST; re-sort MANIFEST. For: RT #124119.
* repeat op: avoid integer overflowsDavid Mitchell2015-03-191-15/+20
| | | | | | | | | | | | | | | | | | | | | | | | For the list variant of the x operator, the overflow detection code doesn't always work, resulting in the stack not being extended enough. There are two places where an overflow could occur: calculating how many stack items to extend by (items * count), and passing to repeatcpy() how many bytes to copy 'items' SV pointers (items * sizeof(const SV *)). The overflow detection was generally a mess; checking for overflow using a value (max) that may have already overflown; checking whether 'max' had overflown incorrectly, and not checking (items * sizeof(const SV *) at all (perhaps hoping that the other checks would be a superset of this). Also, some of the vars were still I32s; promote to 64-bit capable types. Finally, the signature of Perl_repeatcpy() still has an I32 len; that really should be changed to IV at some point; but for now I've just ensured that the callers (list 'x' and scalar 'x') don't wrap. I haven't put in a check for the only other core caller of repeatcpy(), S_study_chunk(), since that would only become an issue compiling a pattern with a fixed or floating substr within it of length > 2**31.
* pp.c: remove unneeded SPAGAIN'sDavid Mitchell2015-03-051-2/+2
| | | | | | | Spotted by Coverity. I've left the SPAGAIN but commented out, in case future changes to the code make them needed again.
* 5th arg to indicate numeric bitwise overloadingFather Chrysostomos2015-01-311-3/+3
|
* Add string- and number-specific bitop typesFather Chrysostomos2015-01-311-18/+125
| | | | | and also implement the pp functions, though nothing compiles to these ops yet.
* avoid C labels in column 0David Mitchell2015-01-211-1/+1
| | | | | | | | | Generally the guideline is to outdent C labels (e.g. 'foo:') 2 columns from the surrounding code. If the label starts at column zero, then it means that diffs, such as those generated by git, display the label rather than the function name at the head of a diff block: which makes diffs harder to peruse.
* Add :const anon sub attributeFather Chrysostomos2015-01-191-0/+11
|
* Catch infnan repeat counts.Jarkko Hietaniemi2015-01-111-8/+17
| | | | | | | | Not entirely convinced this is worth the extra code but getting "Negative repeat count" warning for NaN repeat count is too much. Even before this patch, "a" x $Inf didn't go all Genghis over your virtual memory. This is all about the right warning.
* pp.c pp_split GvAVn can't return NULLDaniel Dragan2015-01-051-0/+3
| | | | | | | clang optimized the function call free branch of GvAVn to skip the "if (ary)" test, but the function call creation branch also will never return NULL (but no CC knows that) so use goto to skip the test on both halfs of GvAVn.
* fix more -IV_MIN negationsDavid Mitchell2014-12-311-5/+9
| | | | | | | | | Doing uv = -iv is undefined behaviour if iv happens to be IV_MIN. This occurs in several places in the perl sources. These ones were found by visual code inspection rather than using -fsanitize=undefined, but I've added extra tests so that -fsanitize could find them now.
* fix -IV_MIN negationsDavid Mitchell2014-12-311-6/+10
| | | | | | | | | | | Doing uv = -iv is undefined behaviour if iv happens to be IV_MIN. This occurs in several places in the perl sources. Found by -fsanitize=undefined. Here's a typical message: sv.c:2864:7: runtime error: negation of -9223372036854775808 cannot be represented in type 'IV' (aka 'long'); cast to an unsigned type to negate this value to itself
* Don't raise 'poorly supported' locale warning unnecessarilyKarl Williamson2014-12-291-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 8c6180a91de91a1194f427fc639694f43a903a78 added a warning message for when Perl determines that the program's underlying locale just switched into is poorly supported. At the time it was thought that this would be an extremely rare occurrence. However, a bug in HP-UX - B.11.00/64 causes this message to be raised for the "C" locale. A workaround was done that silenced those. However, before it got fixed, this message would occur gobs of times executing the test suite. It was raised even if the script is not locale-aware, so that the underlying locale was completely irrelevant. There is a good prospect that someone using an older Asian locale as their default would get this message inappropriately, even if they don't use locales, or switch to a supported one before using them. This commit causes the message to be raised only if it actually is relevant. When not in the scope of 'use locale', the message is stored, not raised. Upon the first locale-dependent operation within a bad locale, the saved message is raised, and the storage cleared. I was able to do this without adding extra branching to the main-line non-locale execution code. This was done by adding regnodes which get jumped to by switch statements, and refactoring some existing C tests so they exclude non-locale right off the bat. These changes would have been necessary for another locale warning that I previously agreed to implement, and which is coming a few commits from now. I do not know of any way to add tests in the test suite for this. It is in fact rare for modern locales to have these issues. The way I tested this was to temporarily change the C code so that all locales are viewed as defective, and manually note that the warnings came out where expected, and only where expected. I chose not to try to output this warning on any POSIX functions called. I believe that all that are affected are deprecated or scheduled to be deprecated anyway. And POSIX is closer to the hardware of the machine. For convenience, I also don't output the message for some zero-length pattern matches. If something is going to be matched, the message will likely very soon be raised anyway.
* Call FETCH once for values in {...}Father Chrysostomos2014-12-291-1/+1
| | | | | I broke this inadvertently in v5.17.5-55-g3ed356d while fixing a memory leak.
* pp.c:pp_quotemeta: No need for PUTBACKFather Chrysostomos2014-12-281-1/+1
| | | | We don’t manipulate the stack pointer at all here.
* Remove PUTBACK/SPAGAIN from hash iter opsFather Chrysostomos2014-12-281-7/+1
| | | | | | | | | | These were added by perl-5a2-2-g463ee0b and perl-5.003-2-gc750a3e. At the time, hv_iternext and hv_iterval could reallocate the stack, but hv_iterkey was safe. perl-5.6.0-8537-g574c802 divorced the comments about hv_iterkey from the lines containing hv_iterkey, making things a bit confusing. Somewhere along the road, all tied hash functionality started being guarded with PUSHSTACK, so these hash functions won’t reallocate the stack any more.
* pp.c:pp_[ul]c(first): No need for PUTBACKFather Chrysostomos2014-12-281-3/+3
| | | | We don’t manipulate the stack pointer at all here.
* pp.c:pp_chr: Less stack fiddlingFather Chrysostomos2014-12-281-5/+5
| | | | | No need for pop and push, since we accept and return one item. No need to extend the stack. No need for PUTBACK.
* pp.c:pp_ord: Less stack fiddlingFather Chrysostomos2014-12-281-3/+3
| | | | | No need for pop and push, since we accept and return one item. No need to extend the stack. No need for PUTBACK.
* pp.c:pp_substr: Redundant PUTBACK/SPAGAINFather Chrysostomos2014-12-281-3/+0
| | | | | These were added in perl-5.004_03-1149-g849ca7e. Perhaps at the time SvPV or sv_magic could reallocate the stack. Neither is true now.
* pp.c:pp_oct: Less stack fiddlingFather Chrysostomos2014-12-281-4/+4
| | | | | No need for pop and push, since we accept and return one item. No need to extend the stack. No need for PUTBACK.
* pp.c:pp_abs: No need for PUTBACKFather Chrysostomos2014-12-281-1/+1
| | | | We don’t manipulate the stack pointer at all here.
* pp.c:pp_negate: No PUTBACK necessaryFather Chrysostomos2014-12-281-6/+6
| | | | We don’t manipulate the stack pointer here.
* pp.c:pp_int: No need for PUTBACKFather Chrysostomos2014-12-281-1/+1
| | | | We don’t manipulate the stack pointer at all here.
* pp.c:pp_sin: Less stack fiddlingFather Chrysostomos2014-12-281-3/+3
| | | | | | No need to pop and push. No need to extend the stack. No need for PUTBACK with those changes, as we no longer maniputale the stack pointer (and even when we did it always ended up with the same value).
View Lorry Controller Status