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 DAB7A3858D38; Mon, 12 Feb 2024 15:28:24 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DAB7A3858D38
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1707751704;
	bh=+rO0WuMznrlla0EEt3AoB0QpH4+dcAwuNgSq9a624Rg=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=xQx982LKYWJXpjuHpgccJoSG3H0kRCL9Kps9Pt5VPnGS/jthTCc7rbveyVAx8YN76
	 3lDCtQfxSyvIZCy1ew+VdRjHgztAo8ETjNFAzmfs/yKBPEB2dfmHgmS5Q8n/EjBZrO
	 BwkU5LJSqfGWjdDYeZbwPUKgtJPpNJNdHcXkMvhA=
From: "ppalka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/113835] [13/14 Regression] compiling std::vector with
 const size in C++20 is slow
Date: Mon, 12 Feb 2024 15:28:24 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 13.2.1
X-Bugzilla-Keywords: compile-time-hog
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ppalka at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-113835-4-tVzd1vp1A1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113835-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113835-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Relatedly, if we actually make x constexpr

#include <vector>
const std::size_t N =3D 1'000'000;
constexpr std::vector<int> x(N);
int main() {}

we end up evaluating its expensive initialization (and hitting the constexpr
loop/ops limit) four times:

1. expand_default_init -> maybe_constant_init
2. store_init_value -> maybe_constant_value
3. store_init_value -> maybe_constant_init
4. store_init_value -> cxx_constant_init

The first three silently fail due to hitting the ops limit, and the fourth
actually diagnoses the failure.  This seems wasteful, we should silently
evaluate such an initializer once.

For the original testcase where x is not constexpr, we constant evaluate the
initialization just once (which silently fails due to the ops limit), which
still takes a few seconds unfortunately.=