[Bug c++/104620] FAIL: g++.dg/cpp23/consteval-if2.C -std=gnu++20 (test for errors)

["ppalka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Some context: consider the simplified/extended C++20 testcase (the consteval-if
seems to be a red herring):

consteval int foo(int x) { return x; }

template<class>
void bar(int x)
{
  constexpr int y = 0;
  foo(8 * x); // #1
  foo(8 * y); // #2
}

Before r12-7264, we would indeed correctly reject #1 ahead of time (which has a
non-constant arg), but we would also incorrectly reject #2 (which has a
constant arg), because both arguments are wrapped in NON_DEPENDENT_EXPR which
cxx_eval_constant_expr considers to be always non-constant.  So essentially we
used to reject the two now-failing tests in consteval-if2.C only by accident.

After r12-7264, is_constant_expr returns false for NON_DEPENDENT_EXPR
(mirroring cxx_eval_constant_expr) which in particular means that
fold_non_dependent_expr no longer tries to check a non-dependent consteval call
ahead of time if it has a "complex" argument (i.e. one that is wrapped in
NON_DEPENDENT_EXPR).  Thus we no longer reject #1 ahead of time, and we also no
longer incorrectly reject #2.  IMHO this is overall an improvement, since not
rejecting #1 ahead of time is a QoI issue, whereas rejecting #2 is a
correctness issue.  This also fixed PR103443 for a similar reason.

(In reply to Jakub Jelinek from comment #3)
> So, either build_non_dependent_arg should be made smarter and not wrap even
> simple arithmetics etc. where no C++ template-ish trees appear inside of it
> and everything is like in normal non-template-ish code, or we should
> reconsider
> the r12-7264 case because clearly often we can handle NON_DEPENDENT_EXPR
> just fine.

I wonder if we can get rid of NON_DEPENDENT_EXPR entirely?  I'm not sure if
it's at all necessary anymore.  Or perhaps we could change tsubst /
is_constant_expr / eval_constant_expr to actually look through
NON_DEPENDENT_EXPR.  These ideas seem out of scope for GCC 12 though :/