On 7/20/23 17:58, Marek Polacek wrote:
On Thu, Jul 20, 2023 at 03:51:32PM -0400, Marek Polacek wrote:
On Thu, Jul 20, 2023 at 02:37:07PM -0400, Jason Merrill wrote:
On 7/20/23 14:13, Marek Polacek wrote:
On Wed, Jul 19, 2023 at 10:11:27AM -0400, Patrick Palka wrote:
On Tue, 18 Jul 2023, Marek Polacek via Gcc-patches wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk and branches?
Looks reasonable to me.
Thanks.
Though I wonder if we could also fix this by not checking potentiality
at all in this case? The problematic call to is_rvalue_constant_expression
happens from cp_parser_constant_expression with 'allow_non_constant' != 0
and with 'non_constant_p' being a dummy out argument that comes from
cp_parser_functional_cast, so the result of is_rvalue_constant_expression
is effectively unused in this case, and we should be able to safely elide
it when 'allow_non_constant && non_constant_p == nullptr'.
Sounds plausible. I think my patch could be applied first since it
removes a tiny bit of code, then I can hopefully remove the flag below,
then maybe go back and optimize the call to is_rvalue_constant_expression.
Does that sound sensible?
Relatedly, ISTM the member cp_parser::non_integral_constant_expression_p
is also effectively unused and could be removed?
It looks that way. Seems it's only used in cp_parser_constant_expression:
10806 if (allow_non_constant_p)
10807 *non_constant_p = parser->non_integral_constant_expression_p;
but that could be easily replaced by a local var. I'd be happy to see if
we can actually do away with it. (I wonder why it was introduced and when
it actually stopped being useful.)
It was for the C++98 notion of constant-expression, which was more of a
parser-level notion, and has been supplanted by the C++11 version. I'm
happy to remove it, and therefore remove the is_rvalue_constant_expression
call.
Wonderful. I'll do that next.
I found a use of parser->non_integral_constant_expression_p:
finish_id_expression_1 can set it to true which then makes
a difference in cp_parser_constant_expression in C++98. In
cp_parser_constant_expression we set n_i_c_e_p to false, call
cp_parser_assignment_expression in which finish_id_expression_1
sets n_i_c_e_p to true, then back in cp_parser_constant_expression
we skip the cxx11 block, and set *non_constant_p to true. If I
remove n_i_c_e_p, we lose that. This can be seen in init/array60.C.
Sure, we would need to use the C++11 code for C++98 mode, which is
likely fine but is more uncertain.
It's probably simpler to just ignore n_i_c_e_p for C++11 and up, along
with Patrick's suggestion of allowing null non_constant_p with true
allow_non_constant_p.
Jason
