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 26DA8385AC1D; Thu, 17 Feb 2022 23:54:46 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 26DA8385AC1D
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/94960] extern template prevents inlining of standard
 library objects
Date: Thu, 17 Feb 2022 23:54:45 +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: 9.1.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi 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: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-94960-4-LH7M8oy1xQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-94960-4@http.gcc.gnu.org/bugzilla/>
References: <bug-94960-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, 17 Feb 2022 23:54:46 -0000

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Erich Keane from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > And if we have to mark every single function as 'inline' then maybe the
> > compiler shouldn't be using it as a hint.
>=20
> I don't think the idea is to mark EVERY function 'inline', simply ones th=
at
> are pretty tiny and really good candidates for inlining.

But that's exactly what we do. _M_construct isn't tiny, it has two loops (a=
nd
until quite recently, a try-catch block, but that's been replaced). There a=
re
some functions in <bits/basic_string.tcc> which are probably small enough t=
o be
marked 'inline', so I should review those. Not for GCC 12 though.

But in C++20 every function is 'constexpr' now, so every function is inline
anyway, right? Even the large functions that aren't good candidates for
inlining (see also PR 93008). So The 'inline' keyword has lost all meaning =
in
<string> now.=