From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 2AF923858C2C; Thu, 24 Mar 2022 14:29:24 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2AF923858C2C
From: "ppalka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/104620] FAIL: g++.dg/cpp23/consteval-if2.C  -std=gnu++20 
 (test for errors)
Date: Thu, 24 Mar 2022 14:29:24 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ppalka at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ppalka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-104620-4-JfyqzC7brr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-104620-4@http.gcc.gnu.org/bugzilla/>
References: <bug-104620-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Mar 2022 14:29:24 -0000

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

--- Comment #7 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> This one is valid, but before your r12-7264 was incorrectly rejected beca=
use
> 8 * baz (0) etc. is wrapped in NON_DEPENDENT_EXPR,
> potential_constant_expression_1 recursed on the NON_DEPENDENT_EXPR operan=
d,
> found it is ok but cxx_eval_constant_expression
> rejected the NON_DEPENDENT_EXPR.

Makes sense, similar to the #2 case in comment #5.

> 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.=20
> potential_constant_expression_1 isn't 100% accurate, there are cases where
> it gets stuff through.

IIUC as long as NON_DEPENDENT_EXPR doesn't appear inside a non-dependent
consteval call then we'll currently correctly accept/reject it ahead of tim=
e,
e.g.:

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

template<class>
void bar(int x)
{
  constexpr int y =3D 0;
  foo(x);     // error: 'x' is not a constant expression
  foo(y);     // OK
  foo(x * 1); // no (ahead of time) error due to NON_DEPENDENT_EXPR
}=