[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, so one problem is that while we save the inline bodies of functions before
cp_fold_function, cp_fold_function is destructive and clobbers the saved copy.
cp_fold itself is (hopefully) not destructive and creates new trees, but
cp_fold_function is destructive and happily modifies the trees shared with
something else (in this case with the constexpr funcdef table).

One way out of this is throwing away cp_fold_r/cp_fold_function and teaching
cp_fold to handle all the trees that cp_walk_tree can walk (dunno if we want to
cache everything or not).  That means handling e.g. STATEMENT_LIST, BIND_EXPR,
*_STMT etc.
Another possibility is to use cp_fold_r the way it is for non-constexpr
functions, and for constexpr functions use instead a hand written walker that
will handle everything that can appear in constexpr functions with copy on
write behavior, say if it is processing a STATEMENT_LIST and determines a
recursive call wants to fold one of the statements, unshare the whole
STATEMENT_LIST, modify it on the copy (and the parent would notice and unshare
etc.).
Yet another possibility is to use the inliner's copy_tree_body_r for this in
register_constexpr_fundef, but in a way that we don't create new decls.  I'm
afraid it would still create new VLA types, can those appear in constexpr
functions?

Jason, any preferences here?

Note, the above would fix the [9 Regression] part of this PR, that we don't
reject that #c4 testcase.  We'd still need to figure out a fix for the [8
Regression] part that once this [9 Regression] part is fixed would become [8/9
Regression].  I guess it could fix various other accepts-invalid cases where
the cp_folding which modifies the saved tree makes us accept invalid constexpr
code.