From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by sourceware.org (Postfix) with ESMTPS id 5F0023858C5F for ; Tue, 25 Jul 2023 02:39:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5F0023858C5F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qt1-x82f.google.com with SMTP id d75a77b69052e-4039a2b71c1so30826251cf.0 for ; Mon, 24 Jul 2023 19:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690252759; x=1690857559; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=g3IV9uHwgpktvmN6leZQl0b4Z4/aaHbgqB4AGyRY7dU=; b=juL7ZLnWNa1db+3ONAr/+KLzKZtLCLRGBbEe1Ekds18yYCNwQnzbkqdletyzBO6a3j vo+vkU/gJd6XfDhaRkXTHESBeM8SmA+CIFajgNUgk8rwn7U6Y/rewVm4s3L+qJA1m05a i/hehxZewZIqBM6K7rT45IX7cCVX5oumyVg8QpIfoMotEeEwfPNu4Glbfy/BGcuTMpeJ aGuhhRaeoGPtEMfGckV2zg+ADJ1CrEJO04AF6WKBoOihIaHdPRQgI4jDKTVKRXs8+vm1 Hbmswn/jwFIoM6KLe3ynByLM/LGx8hThUDr/NK+EYult/ms2kWCJxwcNDDVdOReKplOd tL8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690252759; x=1690857559; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=g3IV9uHwgpktvmN6leZQl0b4Z4/aaHbgqB4AGyRY7dU=; b=UbfHN4pzhhZgCj8+Rl7g0Q6eYfBRUwTDcS+4oVVbT8oux8Vmm3l1HctBwfGyr80xcI OswWREYDx5aqP8B1wKE3R5BLcK0kAZpQVVWJAnOASOwjqLfrMi4OVrHn5xkJzQJnp7gb hXKCgzRhNma3h3yetZoldJYfWH/kb68mzF9t4hUOsiLra0AmATLgWuUWBRes2t7fyWpI dexSrTzGrLYntIznLdl0S9yaSUfpaL2d+E+QDdfdOAbfpyilSLa9XXtFcQ1QHTyk4l2v jpfOZnaaCfqnxTdNmRvtLdyOHikTs143t9kujNgJNWb1P/U+qZhYGlpEkbCbwTHL2JSB d8DA== X-Gm-Message-State: ABy/qLbuj2A85+zMEUN3lJK6poNteApgscV+3EU5kjAf9f/BDapa/BSM x8VFYZoZhRaACXvbTy7/3HLhEQJPgGR5V/q/TZY= X-Google-Smtp-Source: APBJJlGrrNP1D11RXuhmp9Oue+OfGV9rAyQ/y22Hi0si5tyeMkZutjcpJg84Zv/D/di8fT0cgnzxiMB5AP1FlURgJBI= X-Received: by 2002:ac8:5948:0:b0:3fb:426f:19c0 with SMTP id 8-20020ac85948000000b003fb426f19c0mr2055340qtz.29.1690252759603; Mon, 24 Jul 2023 19:39:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Julian Waters Date: Tue, 25 Jul 2023 10:38:38 +0800 Message-ID: Subject: Re: Warning specifically for a returning noreturn To: Jonathan Wakely , gcc@gcc.gnu.org Content-Type: multipart/alternative; boundary="000000000000511d60060146a394" X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000511d60060146a394 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I see. I think it may be appropriate to adopt what clang has done and have one -Winvalid-noreturn for both cases, thoughts? On Fri, Jul 21, 2023 at 5:43=E2=80=AFPM Jonathan Wakely wrote: > On Fri, 21 Jul 2023 at 04:28, Julian Waters via Gcc > wrote: > > > > Hi all, > > > > I've found the places responsible for the warnings, but before I do > > anything I'd like to discuss a couple of things. > > > > 1. What would a good name for the warning switch be? How does > > -Wreturning-noreturn sound? > > 2. I've thought about this for a while, and I feel like throwing a > warning > > for a noreturn method that isn't explicitly noreturn in the Control Flow > > Graph is a little too harsh. The point of the attribute is to hint to g= cc > > that the method will never return even if it appears so, > > Is it? My understanding is that it's for functions the compiler can't > see the body of, e.g. user-defined functions similar to abort(). A > function that doesn't return "even if it appears so" implies the > function body is visible to the compiler. I don't think that's the > primary use case. The compiler is already perfectly capable of > optimizing callers appropriately if the function clearly never > returns, you don't need the attribute for those cases. > > > and requiring that > > the body explicitly do something like call abort() or loop infinitely > kind > > of defeats the purpose of the attribute, in my opinion > > I disagree, because the attribute is for the benefit of the calling > code, not the function body itself. And so it still serves that > purpose whatever the body of the function looks like. > > If you've added the attribute, so that calling code can be optimized > accordingly, but then the body actually does return ... what are you > playing it? That's weird and certainly deserves a warning. The calling > code might not work correctly if the function does return, because > it's been optimized assumed that can never happen, so you cause the > program to have undefined behaviour by returning from a noreturn > function. That certainly deserves a warning. > > The attribute's primary purpose is to inform callers the function > won't return. A side effect of that is that the function itself might > generate warnings if it appears to violate the contract you've made > (that it won't return). To avoid those warnings, you need to write the > function body so that it doesn't return. So instead of allowing the > function to return, call another noreturn function (like abort), or > add a __builtin_unreachable (or call std::unreachable in C++23), or > throw an exception. > > > 3. > If (2) is just me missing something, should I split the warning into 2 > > different warnings for a noreturn definition with an explicit return > > statement and an implicit one in the case of a method not explicitly > > throwing/looping infinitely, etc? > > I'm not sure it's worth it, as they're closely related. Although I > suppose you could have a noreturn function that must have a non-void > return type in order to conform to some expected API (e.g. a virtual > function, or a function who's address is taken and used as a > callback), so want to disable the warning about a non-void return, but > still get warnings for the function body to help you ensure it really > doesn't return by mistake. > --000000000000511d60060146a394--