On Fri, Mar 8, 2019 at 12:45 PM Jakub Jelinek <ja...@redhat.com> wrote: > > On Fri, Mar 08, 2019 at 12:25:31PM +0100, Jakub Jelinek wrote: > > Maybe. The question is what exactly should we count. We could count only > > in the cxx_eval_statement_list loop individual non-debug statements, > > but that would miss statements that aren't in STATEMENT_LISTs. > > Or we could count number of cxx_eval_constant_expression calls > > (perhaps after the initial if (jump_target && *jump_target) skipping) > > within a single cxx_eval_outermost_constant_expr, but we couldn't call that > > number of statements even when it would be much more accurate on how long > > actually something will take to evaluate, because one can have a single > > statement with hundreds of thousands of operations in it. > > So -fconstexpr-ops-limit= ? Probably should use Host_Wide_Int in that case > > rather than UInteger though, so users can allow more than 4G ops. > > Or, if we wanted to count statements, perhaps count just specific subset > of tree codes in cxx_eval_statement_list, like *_STMT, RETURN_EXPR, > SWITCH_EXPR, anything else that must be a statement rather than some > subexpression and is usually not wrapped with EXPR_STMT? > > Or count both statements and ops and have two limits. > > With the ops limit I'm afraid even if we have quite high default, it might > trigger if people use huge multi-megabyte constexpr arrays or similar.
Well, I think having only a single limit is desirable which means we have to count something resembling the overall work done. We don't have to document that it matches "statements" (whatever that exactly would be). I don't see multi-megabyte constexpr arrays as an issue - do you think we'd reject them already when parsing them? We could always decide to elide counting things we didn't do any real work on (like a literal '1' initializer). Richard. > Jakub
