From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sourceware.org (Postfix) with ESMTPS id 4563E3858C50 for ; Mon, 2 May 2022 12:26:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4563E3858C50 X-IronPort-AV: E=Sophos;i="5.91,192,1647298800"; d="scan'208";a="34271757" Received: from 85-171-189-19.rev.numericable.fr (HELO hippo) ([85.171.189.19]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 May 2022 14:26:22 +0200 Date: Mon, 2 May 2022 14:26:18 +0200 (CEST) From: Marc Glisse Reply-To: gcc@gcc.gnu.org To: Boris Kolpackov cc: gcc@gcc.gnu.org Subject: Re: GCC 12.1 Release Candidate available from gcc.gnu.org In-Reply-To: Message-ID: <6b76a0f7-df1d-934-b77c-6b89f11a6594@hippo.saclay.inria.fr> References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2022 12:26:25 -0000 On Mon, 2 May 2022, Boris Kolpackov wrote: > Jakub Jelinek writes: > >> The first release candidate for GCC 12.1 is available [...] > > There is an unfixed bogus warning that is a regression in 12 > and that I think will have a pretty wide effect (any code > that assigns/appends a 1-char string literal to std::string): > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 > > For example, in my relatively small codebase I had about 20 > instances of this warning. Seeing that it's enabled as part > of -Wall (not just -Wextra), I believe there will be a lot > of grumpy users. > > There is a proposed work around in this (duplicate) bug that > looks pretty simple: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336 > > Perhaps it makes sense to consider it? Please no, that workaround looks like a fragile hack (basically writing a+b-a to obfuscate b) that may break if you look at it sideways and likely makes the generated code a bit worse. Besides, we should take it as a hint that user code is also likely to trigger the warning by accident. IMO there are several ways to make progress on this in parallel: * improve the optimizer (as investigated by Andrew) * tweak the warning so it becomes either cleverer or less eager (maybe even use the fact that this special case is in a system header? that should be a last resort though) * battle that has already been lost, no need to rehash it: --- a/gcc/c-family/c.opt +++ b/gcc/c-family/c.opt @@ -1450,3 +1450,3 @@ Warn when a declaration has duplicate const, volatile, restrict or _Atomic speci Wrestrict -C ObjC C++ ObjC++ Var(warn_restrict) Warning LangEnabledBy(C ObjC C++ ObjC++, Wall) +C ObjC C++ ObjC++ Var(warn_restrict) Warning LangEnabledBy(C ObjC C++ ObjC++, Wextra) Warn when an argument passed to a restrict-qualified parameter aliases with Or admit that --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -5729,4 +5729,3 @@ by this option and not enabled by the latter and vice versa. This enables all the warnings about constructions that some users -consider questionable, and that are easy to avoid (or modify to -prevent the warning), even in conjunction with macros. This also +consider questionable. This also enables some language-specific warnings described in @ref{C++ Dialect -- Marc Glisse