This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ Patch] PR 89571 ("[9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238")
Hi,
On 14/03/19 21:03, Jason Merrill wrote:
On 3/12/19 7:21 AM, Paolo Carlini wrote:
Hi,
this is just an error recovery ICE but maybe we can fix it in time
for 9.1.0, like c++/89488, which is somehow related. Indeed, the
problem is again a !DEFERRED_NOEXCEPT_SPEC_P gcc_assert triggering
where, earlier, process_subob_fn had maybe_instantiate_noexcept
returning false (in c++/89448 the assertion triggered almost
immediately, when merge_exception_specifiers was called).
Anyway, what we committed for c++/89488 doesn't help here because the
error_mark_node assigned to *spec_p is propagated back only up to
build_over_call, where mark_used returns false but isn't acted upon
because of the additional && !(complain & tf_error). Thus I had the
idea of simply removing the latter (by itself a bit invasive at this
stage) but that leads to duplicated diagnostics because then, in
cp_parser_decltype_expr, when cp_parser_postfix_expression returns
error_mark_node we go on and try a full expression too, and emit the
same diagnostics again.
Given the above we can imagine reworking the parser, which seems to
me a bit tricky at this time, or we can go back to my initial
proposal for c++/89488, attached below, which doesn't set *spec_p to
error_mark_node when maybe_instantiate_noexcept returns false. My
rationale being that, elsewhere, we very often discard completely the
return value of maybe_instantiate_noexcept, thus it doesn't seem a
big deal only using it to avoid immediately calling
marge_exception_specifiers and ICE. If we do this, for c++/89448 we
emit the additional "cannot convert" error, which may not be a bad
thing, given that we used to emit it forever, and the same do both
clang and edg, thus it looks like considering that 'zl ()' not
completely broken may make sense for error-recovery purposes...
The thing is, we need to defer instantiation of a noexcept-specifier
that depends on a DMI we haven't parsed yet, since it can succeed
later and we don't want to have given up and said false.
But other cases of failed instantiation we can and should diagnose
once and then recover from. What do you think about this approach?
Oh, nice, I didn't go that far... However, I definitely wanted to spend
more time on that if (spec ==error_mark_node) return false; which seemed
at the center of the issues we were having.
Anyway, I'm reassigning the bug to you.
Thanks! Paolo.