From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id DA1B13858025; Fri, 10 Dec 2021 18:16:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DA1B13858025 Received: by mail-wr1-x431.google.com with SMTP id t18so16280263wrg.11; Fri, 10 Dec 2021 10:16:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dvxj/l5zFOLmc4qcLxE3Bn3vS94nPZUcuN2UG/VqYV4=; b=R3nVdc4gwg8KOZ7XUtl5iI5KWMG+K5wNQNTNfYHRS3KdNzODw3JxVGhj3c9gAKH8yb rj12hj8e1TUkYRgCbQ3GeGnX4PFJZu+EibWMaWA7NKQZoKsokCzaKkLHOelDGSMMX9kj 3XW+Pv4dAIEMeFlxe8FRX6kyF/rxUGv6giSb7mKKO4OhFzESONnew6ZRK5p/AJZsL9c8 GxjdkkP54uDCJYY2qrS9BvugqW+PgmQAWXm2drNK1lfmXabRvNzaXkuiSgQcEmLdLejm fPLmw8Ka85ZC4FA/CZR2bsW5MqR7tXeM4KjaYpAwc/30x7A+XpxuSiElbDDuUs0T4wUp 8YYQ== X-Gm-Message-State: AOAM5327F/1eP5NUKc7ubJyURQ9DIB5lNDJDW3b6LcxYRvXqgrIWd+zD r5yFtPX/z4boJdxTytwFBqOfC/EdxVhzedqsBGM= X-Google-Smtp-Source: ABdhPJxWNT47KOb3QQzBirEqLsBM9U4Noilpe9LOBXiLwfTSxUUCqbc736PfESoxd8QlropBClmtpzEVlRCAZlwmHT0= X-Received: by 2002:a5d:4a0a:: with SMTP id m10mr15425848wrq.221.1639160176851; Fri, 10 Dec 2021 10:16:16 -0800 (PST) MIME-Version: 1.0 References: <20211209232453.1568609-1-jwakely@redhat.com> <8a43115a-fab5-e2e7-6737-e0fbc43ebb59@gmail.com> <20211210164105.GP2646553@tucnak> <8f8789ad-a8a1-bc3b-da39-cb0dc52b3d71@gmail.com> <20211210171749.GR2646553@tucnak> In-Reply-To: <20211210171749.GR2646553@tucnak> From: Jonathan Wakely Date: Fri, 10 Dec 2021 18:16:05 +0000 Message-ID: Subject: Re: [committed] libstdc++: Disable over-zealous warnings about std::string copies [PR103332] To: Jakub Jelinek Cc: Martin Sebor , "libstdc++" , gcc-patches , Jonathan Wakely Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2021 18:16:19 -0000 On Fri, 10 Dec 2021 at 17:17, Jakub Jelinek wrote: > > 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. Every member function of std::string is constexpr in C++20, but not before. But we could add constexpr to internal _M_xxx functions if that benefits optimization. For std::basic_string::max_size() it has to call another function provided by the allocator, but for the std::string (i.e. std::basic_string, allocator>) specialization we know what the allocator is going to tell us. --- a/libstdc++-v3/include/bits/basic_string.h +++ b/libstdc++-v3/include/bits/basic_string.h @@ -1071,7 +1071,12 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 _GLIBCXX20_CONSTEXPR size_type max_size() const _GLIBCXX_NOEXCEPT - { return (_Alloc_traits::max_size(_M_get_allocator()) - 1) / 2; } + { + if _GLIBCXX17_CONSTEXPR (__are_same>) + return size_t(-1) / 2; + else + return (_Alloc_traits::max_size(_M_get_allocator()) - 1) / 2; + } /** * @brief Resizes the %string to the specified number of characters.