https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104620
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Another testcase to consider is:
consteval int foo (int x) { return x; }
consteval int bar () { return 2; }
constexpr int baz (int x) { return x; }
template <typename T>
constexpr int
qux (int x)
{
int r = 0;
if consteval // { dg-warning "'if consteval' only available with" ""
{ target c++20_only } }
{
r += 2 * bar ();
}
else
{
r += foo (8 * baz (0));
}
if ! consteval // { dg-warning "'if consteval' only available with" ""
{ target c++20_only } }
{
r += foo (32 * baz (0));
}
if consteval // { dg-warning "'if consteval' only available with" ""
{ target c++20_only } }
{
r += 32 * bar ();
}
return r;
}
This one is valid, but before your r12-7264 was incorrectly rejected because 8
* baz (0) etc. is wrapped in NON_DEPENDENT_EXPR,
potential_constant_expression_1 recursed on the NON_DEPENDENT_EXPR operand,
found it is ok but cxx_eval_constant_expression
rejected the NON_DEPENDENT_EXPR. Bet for the build_over_call
processing_template_decl immediate_invocation_p code we need to punt silently
if there is something we can't handle but fail loudly if we can handle
everything but it is clearly always not a constant expression.
potential_constant_expression_1 isn't 100% accurate, there are cases where it
gets stuff through.
