https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 45666 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45666&action=edit gcc9-pr89285-wip.patch Non-working WIP. I've tried this, thinking that we don't really need to duplicate decls etc. in the function and could just copy the statements. Unfortunately, there are issues with that: 1) the genericization modifies in place the PARM_DECLs and RESULT_DECL, so mixing the pre-cp_fold_function/cp_genericize* statements (body) with the post cp_genericize* is not going to work flawlessly 2) apparently cxx_eval_constant_expression assumes post genericization IL: if (STATEMENT_CODE_P (TREE_CODE (t))) { /* This function doesn't know how to deal with pre-genericize statements; this can only happen with statement-expressions, so for now just fail. */ if (!ctx->quiet) error_at (EXPR_LOCATION (t), "statement is not a constant expression"); } so it is upset e.g. about WHILE_STMT and others. >From the language conformance POV though, I think it is highly desirable to evaluate constexpr functions on the original, pre-folding/genericization, trees, because the middle-end (e.g. match.pd, fold-const.c) is not willing to guarantee not to fold away stuff that should be diagnosed as constexpr violations. So, for 1), I'd think we could just use copy_fn and remember not just the body, but also parms and result in constexpr_fundef For 2), I guess that would mean teaching constexpr.c about the pre-genericization *_STMT constructs.
