-
Notifications
You must be signed in to change notification settings - Fork 577
op.c: 'clobbered' warning becomes un-silenced with g++-8 #16716
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
Comments
From @jkeenanIn Oct 2016 a commit made a one-line modification to op.c so as to ##### op.c: silence compiler warning in fold_constants() op.c: In function ‘S_fold_constants’: This warning occurs for non-volatile local variables where the Inline Patchdiff --git a/op.c b/op.c
index ebbbf81a5a..cf1399ebbe 100644
--- a/op.c
+++ b/op.c
@@ -4371,7 +4371,7 @@ S_op_integerize(pTHX_ OP *o)
}
static OP *
-S_fold_constants(pTHX_ OP *o)
+S_fold_constants(pTHX_ OP *const o)
{
dVAR;
OP * VOL curop;
Unfortunately, if you compile with g++8, this warning reappears. From a ##### Can this be alleviated? Thank you very much. |
From @jkeenanSummary of my perl5 (revision 5 version 29 subversion 4) configuration: Characteristics of this binary (from libperl): |
From @iabynOn Wed, Oct 10, 2018 at 12:12:51PM -0700, James E Keenan (via RT) wrote:
In general I think our approach to the longjmp warnings should be -- |
The RT System itself - Status changed from 'new' to 'open' |
From @tonycozOn Mon, 15 Oct 2018 04:01:54 -0700, davem wrote:
Something like the attached? Tony |
From @tonycoz0001-perl-133575-prevent-set-longjmp-clobbering-locals-in.patchFrom 7ba450c0cc472a49f30902abd01e5ca021aa264b Mon Sep 17 00:00:00 2001
From: Tony Cook <[email protected]>
Date: Thu, 3 Jan 2019 10:48:05 +1100
Subject: (perl #133575) prevent set/longjmp clobbering locals in
S_fold_constants
My original approach moved the whole switch into the new function,
but that was a lot messier, and I don't think it's necessary.
pad_swipe() can throw, but only for panics, and in DESTROY if
refadjust is true, which isn't the case here.
CLEAR_ERRSV() might throw if the code called by CALLRUNOPS()
puts an object that dies in DESTROY in $@, but I think that
might cause an infinite loop in the original code.
---
op.c | 32 ++++++++++++++++++++++++--------
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/op.c b/op.c
index 146407ba70..0b46b348cb 100644
--- a/op.c
+++ b/op.c
@@ -5464,15 +5464,34 @@ S_op_integerize(pTHX_ OP *o)
return o;
}
+/* This function exists solely to provide a scope to limit
+ setjmp/longjmp() messing with auto variables.
+ */
+PERL_STATIC_INLINE int
+S_fold_constants_eval(pTHX) {
+ int ret = 0;
+ dJMPENV;
+
+ JMPENV_PUSH(ret);
+
+ if (ret == 0) {
+ CALLRUNOPS(aTHX);
+ }
+
+ JMPENV_POP;
+
+ return ret;
+}
+
static OP *
S_fold_constants(pTHX_ OP *const o)
{
dVAR;
- OP * volatile curop;
+ OP *curop;
OP *newop;
- volatile I32 type = o->op_type;
+ I32 type = o->op_type;
bool is_stringify;
- SV * volatile sv = NULL;
+ SV *sv = NULL;
int ret = 0;
OP *old_next;
SV * const oldwarnhook = PL_warnhook;
@@ -5480,7 +5499,6 @@ S_fold_constants(pTHX_ OP *const o)
COP not_compiling;
U8 oldwarn = PL_dowarn;
I32 old_cxix;
- dJMPENV;
PERL_ARGS_ASSERT_FOLD_CONSTANTS;
@@ -5582,15 +5600,15 @@ S_fold_constants(pTHX_ OP *const o)
assert(IN_PERL_RUNTIME);
PL_warnhook = PERL_WARNHOOK_FATAL;
PL_diehook = NULL;
- JMPENV_PUSH(ret);
/* Effective $^W=1. */
if ( ! (PL_dowarn & G_WARN_ALL_MASK))
PL_dowarn |= G_WARN_ON;
+ ret = S_fold_constants_eval(aTHX);
+
switch (ret) {
case 0:
- CALLRUNOPS(aTHX);
sv = *(PL_stack_sp--);
if (o->op_targ && sv == PAD_SV(o->op_targ)) { /* grab pad temp? */
pad_swipe(o->op_targ, FALSE);
@@ -5608,7 +5626,6 @@ S_fold_constants(pTHX_ OP *const o)
o->op_next = old_next;
break;
default:
- JMPENV_POP;
/* Don't expect 1 (setjmp failed) or 2 (something called my_exit) */
PL_warnhook = oldwarnhook;
PL_diehook = olddiehook;
@@ -5616,7 +5633,6 @@ S_fold_constants(pTHX_ OP *const o)
* the stack - eg any nested evals */
Perl_croak(aTHX_ "panic: fold_constants JMPENV_PUSH returned %d", ret);
}
- JMPENV_POP;
PL_dowarn = oldwarn;
PL_warnhook = oldwarnhook;
PL_diehook = olddiehook;
--
2.11.0
|
From @jkeenanOn Thu, 03 Jan 2019 00:29:16 GMT, tonyc wrote:
Made available for smoke-testing in this branch: smoke-me/jkeenan/tonyc/133575-longjmp-clobbering -- |
From @jkeenanOn Thu, 03 Jan 2019 15:51:38 GMT, jkeenan wrote:
Configuring on FreeBSD-11.2 as follows: ##### ... I built perl on blead and in the smoke-me/jkeenan/tonyc/133575-longjmp-clobbering branch. Here is a diff of the 'make' output: ##### So the '-Wclobbered' warning has been successfully squelched in the branch. See also this smoke-test report where I built the branch on Linux with gcc-8 and g++-8 and avoided all '-Wclobbered' warnings: http://perl5.test-smoke.org/report/77558 So, unless there's some flaw in the C-code I don't see, I think the patch should be applied. Thank you very much. -- |
@tonycoz - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for filing this report. You have helped make Perl better. With the release today of Perl 5.30.0, this and 160 other issues have been Perl 5.30.0 may be downloaded via: If you find that the problem persists, feel free to reopen this ticket. |
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#133575 (status was 'resolved')
Searchable as RT133575$
The text was updated successfully, but these errors were encountered: