[committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332]

Jakub Jelinek jakub@redhat.com
Fri Dec 10 17:17:49 GMT 2021


On Fri, Dec 10, 2021 at 10:11:04AM -0700, Martin Sebor via Gcc-patches wrote:
> On 12/10/21 9:41 AM, Jakub Jelinek wrote:
> > On Fri, Dec 10, 2021 at 09:35:50AM -0700, Martin Sebor via Gcc-patches wrote:
> > > The above was just a quick proof of concept experiment.  You're
> > > of course right that the final solution can't be so crude(*).
> > > But if the required functions are always_inline (I think member
> > > functions defined in the body of the class implicitly are
> > 
> > They are not, and can't be, nothing says that such member functions
> > can't use constructs that make it uninlinable (with always_inline
> > that would be an error), or are way too large that inlining is not
> > desirable, etc.  They are just implicitly inline.
> 
> The functions we're talking about are the trivial max_size()
> members of std::string and allocator traits.  They just return
> a constant.
> 
> But I see I was wrong, even member functions have to be explicitly
> declared always_inline to be guaranteed to be inlined even at -O0.
> I don't think that should be an issue for the trivial max_size()
> (at least not for the std::string specialization).

Note, if those functions are declared constexpr, without -fno-inline
(default at -O0), then cp_fold will try to evaluate such calls to constant
expressions already, effectively "inlining" them.

	Jakub



More information about the Gcc-patches mailing list