op.c:newPADOP: Allocate GV pad slots like constants

Requesting a pad slot for a constant (and GVs in pads are like con-
stants, in that the pad slot will always hold that same value, which
is shared in recursion) will instruct pad_alloc to avoid anything
marked PADTMP; i.e., a  slot used as a target by a previous statement.

Without this, under -Accflags=-DUSE_BROKEN_PAD_RESET and threads,
configpm fails an assertion, because a concat operator tries to do
sv_grow on its target, but that target has ended up becoming a GV.

With this commit, all tests pass, but t/re/uniprops.t takes ‘forever’
(cf. commits 325e1816 and 7db6405c, which caused and fixed, respec-
tively, a similar bug).

diff --git a/op.c b/op.c
index 357a524..abeea58 100644 (file)
--- a/op.c
+++ b/op.c
@@ -5202,7 +5202,8 @@ Perl_newPADOP(pTHX_ I32 type, I32 flags, SV *sv)
     NewOp(1101, padop, 1, PADOP);
     padop->op_type = (OPCODE)type;
     padop->op_ppaddr = PL_ppaddr[type];
-    padop->op_padix = pad_alloc(type, SVs_PADTMP);
+    padop->op_padix =
+       pad_alloc(type, IS_PADGV(sv) ? SVf_READONLY : SVs_PADTMP);
     SvREFCNT_dec(PAD_SVl(padop->op_padix));
     PAD_SETSV(padop->op_padix, sv);
     assert(sv);