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 65CB93858401; Mon,  5 Dec 2022 22:28:00 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 65CB93858401
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1670279280;
	bh=/uHIvGL8KDEddV3EkEVlcOtbwY3I66T81a7DFWuYOUk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=WyKukNDRpdZdDA8+d8WTHo8C2UKWH+P1mNdUUIOjdGQsnaa5UjGZ0jFZFnu2/4qYi
	 Sts1jMU8W4G80RA8F6fkK22tIcG5NhW3HZgwEGUFfd5gltZLGkQc+tL4PFh5X13p4u
	 abvkEWSG9AlEYKl5EglVBUueTy1mUWPEcXhka7UE=
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/105838] [10/11/12/13 Regression] g++ 12.1.0 runs out of
 memory or time when building const std::vector of std::strings
Date: Mon, 05 Dec 2022 22:27:59 +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.1.0
X-Bugzilla-Keywords: compile-time-hog, memory-hog
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 10.5
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-105838-4-igNdLnMV5B@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-105838-4@http.gcc.gnu.org/bugzilla/>
References: <bug-105838-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=3D105838

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #12)
> Another significant part of the problem is that vector<string> doesn't ha=
ve
> a generic initializer_list constructor.  Adding
>=20
>       template <typename __elt>
>       _GLIBCXX20_CONSTEXPR
>       vector(initializer_list<__elt> __l,
>              const allocator_type& __a =3D allocator_type())
>       : _Base(__a)
>       {
>         _M_range_initialize(__l.begin(), __l.end(),
>                             random_access_iterator_tag());
>       }
>=20
> so that it can construct from initializer_list<const char *> makes the
> construction into a simple loop over a static array.

Which is potentially *much* more efficient, because it constructs the strin=
gs
in place, instead of making unelidable copies of the initializer_list eleme=
nts.

> Jonathan, has anyone suggested adding generic init_list constructors to t=
he
> container classes?

Not that I'm aware of. There might be concerns about introducing more
ambiguities like the vector<int>{1,2} case.

> What do you think about doing the above translation in the compiler?  Is =
the
> compiler allowed to do that?

Good question.

If the compiler first checked that the code as-written would call the
initializer_list<value_type> constructor (and not some other constructor) t=
hen
it should be safe to do it.

In the general case, somebody would probably find a way to notice and compl=
ain.
But if you're thinking of optimizing the specific case of vector<string> th=
en I
think it would be unobservable. The string copies can't be observed, because
it's unspecified when and how often std::allocator calls operator new.=