https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113835
--- Comment #16 from Jason Merrill <jason at gcc dot gnu.org> --- (In reply to Patrick Palka from comment #4) > r13-6421 just makes us use mce_true and mce_uknown during trial constant > evaluation of x's initialization, so my guess is before that commit the > evaluation was quickly aborted as soon as it saw a > std::is_constant_evaluated() call, and afterwards we evaluate > is_constant_evaluated() to true and keep going until we hit > constexpr_loop_limit / constexpr_ops_limit. So perhaps we should have > reduced limits for trial constant evaluation? The issue is that as I mentioned in comment #10, the trial mce_unknown evaluation was the only evaluation, so before that commit the evaluation was quickly aborted and then we never try again. So it's not clear to me that this is a regression: now we are actually trying to do manifest constant-initialization as specified by the standard, and failing due to implementation limits. Previously we wrongly didn't try. Admittedly, we end up with the same result after taking much longer, so that's definitely a regression in the user experience. Incidentally, perhaps we want to give a diagnostic about hitting implementation limits even in contexts like this that allow non-constant results.
