On 11/18/22 10:03, Marek Polacek wrote:
On Fri, Nov 18, 2022 at 08:48:32AM +0100, Jakub Jelinek wrote:
On Thu, Nov 17, 2022 at 07:15:05PM -0500, Marek Polacek wrote:
--- gcc/cp/decl.cc.jj 2022-11-16 14:44:43.692339668 +0100
+++ gcc/cp/decl.cc 2022-11-17 20:53:44.102011594 +0100
@@ -5600,6 +5600,57 @@ groktypename (cp_decl_specifier_seq *typ
return type;
}
+/* For C++17 and older diagnose static or thread_local decls in constexpr
+ or consteval functions. For C++20 similarly, except if they are
In C++17 we don't support consteval so I guess drop the "or consteval "?
I just forgot to update the function comment.
Anyway, I think:
BTW, I notice that the patch breaks
g++.dg/cpp1y/lambda-generic-func1.C
g++.dg/cpp1z/constexpr-lambda16.C
Maybe they just need dg- tweaks.
this is actually a real bug and I'm not sure how to resolve that.
We have there:
int main()
{
[](auto i) { if (i) { int j; static int k; return i + j; } return i; }(0);
}
and for C++17/20 I presume something (haven't figured out yet what) marks
Right, that's the C++17 implicit constexpr for lambdas, finish_function:
/* Lambda closure members are implicitly constexpr if possible. */
if (cxx_dialect >= cxx17
&& LAMBDA_TYPE_P (CP_DECL_CONTEXT (fndecl)))
DECL_DECLARED_CONSTEXPR_P (fndecl)
= ((processing_template_decl
|| is_valid_constexpr_fn (fndecl, /*complain*/false))
&& potential_constant_expression (DECL_SAVED_TREE (fndecl)));
Yeah, I guess potential_constant_expression needs to be stricter in a
lambda. Or perhaps any function that isn't already
DECL_DECLARED_CONSTEXPR_P?
the lambda operator() when still a template as constexpr and then
cp_finish_decl -> diagnose_static_in_constexpr pedwarns on it.
For the above perhaps we could figure out there is a static int k; in the
operator() and don't turn it into constexpr, but what if there is
something that would e.g. satisfy decl_maybe_constant_var_p but not
decl_constant_var_p when actually instantiated?
I'd expect the above change to potential_c_e to handle that case.
Jason
