On 2/26/19 5:42 AM, Paolo Carlini wrote:
Hi,
the issue is rather easy to explain: after Alexandre' change in
r266874, which simplified the condition at the beginning of
build_noexcept_spec to evaluate early all the expressions which aren't
deferred or value-dependent, we obviously ICE during error-recovery on
the new testcase because an expression which isn't a potential constant
filters through and cxx_constant_value can't handle it. We can avoid
this in various ways - for example by adding a gate &&
potential_rvalue_constant_expression_p (expr) in the condition at the
beginning of build_noexcept_spec and adjust/remove the final gcc_assert
(which is already a bit obsolete wrt Alexandre' change). Or we can
handle this earlier, in cp_parser_noexcept_specification_opt - in
complete analogy, with, say, cp_parser_initializer_list - thus don't let
through those expressions at all (possible variant: set expr =
error_mark_node), which has the advantage of avoiding a duplicate
potential_rvalue_constant_expression call (note: in the parser
build_no_except_spec is called only by
cp_parser_noexcept_specification_opt)
All those variants pass the testsuite on x86_64-linux.
What happens if 'sm' is constexpr?
Jason
