From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id AF2E63858421 for ; Wed, 5 Jul 2023 13:29:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AF2E63858421 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-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-3fbc1218262so81468685e9.3 for ; Wed, 05 Jul 2023 06:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688563747; x=1691155747; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CxlxlN7UWRI6lEWoUjIRFKKL3NO6sc0LvHju9jXJ0t0=; b=sChI0NgZ9h8KxEPIkBBpt5K+I6R7IENyF8old+RVkBlD9qDSY3FnP50VIpq0mZQ1f7 fOS8yxnAuMFy/w71UO6dqNuz2sefa6zbMC32BHz2DcuK9F5/zC9nvMFYBpaen52DOaZB YajFN3UkSnk9sfVa/3/uLiIWHI0gTOCvZZlalJU5JuC9Z2jKFHp4THM+7UfGfVU2KC4O LMpLdSPShThEgKt6I9W+VoBYHsLcxtjRM2/bRbEIlHIZABZ1A9tTA7yOpxgnt6V1E5+w m39A964e5WW8S030v15ogHIruEnKRioDilo65FffO5CbjOkvB9SHCmi2xkwmN2l3K2rG T3WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688563747; x=1691155747; h=cc: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=CxlxlN7UWRI6lEWoUjIRFKKL3NO6sc0LvHju9jXJ0t0=; b=MZYU5OBwyPdbj80jizVGmQuG8gSEZjNCnBuieT0A+qfamHFnvfKxZQl/1c/kW4AkgA 26N/FqsJYsI+/m6t6OSNvX7QIjX3JA54oXHUYzr6ctZBHG+Js5z/zc70D/MfuPQyR590 0mQXZqzMET/f8p1RkCTMWR6vAHQtlQdlj9dMee3mFiNOD8x07kYazk4hRGrsGZfbMZ5i rz7+e+5URntRNF4JWhaEFU0qTQWBFKPJrExeK2/amN3c8O1KF0Xvn0RyyfdhH7UOqR6r zp6cym4Rnf+PodnyZN9N/rbr4WT4I4omF5YrqFjSLkSfDsUG4UoLblb+xFUJtDb9UGx6 UBkA== X-Gm-Message-State: ABy/qLalM1nHYO7umZgG+i9uemcjSdRcssc73hYpLrXg0JK+/8eIJOUw QHufI13etOMK9kCGOR8463hwwNNXpbj9BmCZP6EelH7u X-Google-Smtp-Source: APBJJlHnFknW6bzpFTRFUFnrTwkrw8RmDtj3L8Cjw/R9vHIMDk7IydjqUVwlAFLdOgGb0ruDhzu/vXKVPEhmoB+n9Iw= X-Received: by 2002:a17:906:f9d7:b0:988:9621:d855 with SMTP id lj23-20020a170906f9d700b009889621d855mr9443790ejb.61.1688563226082; Wed, 05 Jul 2023 06:20:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Wed, 5 Jul 2023 14:20:13 +0100 Message-ID: Subject: Re: Warning specifically for a returning noreturn To: Julian Waters Cc: "gcc@gcc.gnu.org" Content-Type: multipart/alternative; boundary="00000000000045806c05ffbd4335" X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000045806c05ffbd4335 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 5 Jul 2023, 14:13 Julian Waters, wrote: > Hi Jonathan, > > Thanks for the reply, is there a place in gcc's source code I could look > at for this? > This is a commit where I added four new warnings, and then changed the code that issues those warnings to use the new OPT_Wxxx variables: https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3Dee336ecb2a7161bc28f6c53= 43d97870a8d15e177 You would want you do something similar. Define a warning in c.opt, then find where that warning is printed and change the 0 to OPT_Wreturn_in_noreturn (or whatever you call the new flag). More generally, new options go in gcc/c-fsmily/c.opt so there are several examples of adding new warnings in the history for that file: https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dhistory;f=3Dgcc/c-family/c.opt;h= =3D4abdc8d0e77c6bded20829e35ac550c3a1b994dd;hb=3Drefs/heads/master As for the returning an explicit value from noreturn, I'm unfortunately not > the one who wrote the code that way; I'm merely a build systems developer > trying to get it to work with gcc :/ > > best regards, > Julian > > On Wed, 5 Jul 2023, 19:26 Jonathan Wakely, wrote: > >> On Wed, 5 Jul 2023 at 12:01, Julian Waters via Gcc >> wrote: >> > >> > I see, thanks Andrew. >> > >> > Anyone else have opinions on this besides Liu or Andrew? The responses >> have >> > been surprisingly quiet thus far >> >> IMHO all warnings should have an option controlling them, so that you >> can disable them via pragmas. >> >> But I agree that you shouldn't need to return from a noreturn >> function, it can either throw or use __builtin_unreachable() on the >> line where you currently return. >> >> >> > >> > best regards, >> > Julian >> > >> > On Wed, 5 Jul 2023, 09:40 Andrew Pinski, wrote: >> > >> > > On Tue, Jul 4, 2023 at 6:32=E2=80=AFPM Julian Waters > > >> > > wrote: >> > > > >> > > > Hi Andrew, thanks for the quick response, >> > > > >> > > > What if the method has a return value? I know it sounds >> > > counterintuitive, but in some places HotSpot relies on the noreturn >> > > attribute being applied to methods that do return a value in an >> unreachable >> > > code path. Does the unreachable builtin cover that case too? >> > > >> > > It is wrong to use noreturn on a function other than one which has a >> > > return type of void as documented. >> > > >> > > >> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index= -noreturn-function-attribute >> > > : >> > > ``` >> > > It does not make sense for a noreturn function to have a return type >> > > other than void. >> > > ``` >> > > >> > > Thanks, >> > > Andrew Pinski >> > > >> > > >> > > > >> > > > best regards. >> > > > Julian >> > > > >> > > > On Wed, Jul 5, 2023 at 9:07=E2=80=AFAM Andrew Pinski >> wrote: >> > > >> >> > > >> On Tue, Jul 4, 2023 at 5:54=E2=80=AFPM Julian Waters via Gcc < >> gcc@gcc.gnu.org> >> > > wrote: >> > > >> > >> > > >> > Hi all, >> > > >> > >> > > >> > Currently to disable the warning that a noreturn method does >> return, >> > > it's >> > > >> > required to disable warnings entirely. This can be very >> inconvenient >> > > when >> > > >> > -Werror is enabled with a noreturn method that isn't specifical= ly >> > > calling >> > > >> > something like std::abort() at the end, when one wants all other >> > > -Wall and >> > > >> > -Wextra warnings to be reported, for instance in the Java >> HotSpot VM >> > > (which >> > > >> > I'm currently adapting to compile with gcc on all supported >> > > platforms). Is >> > > >> > there a possibility we can add a disable warning option >> specifically >> > > for >> > > >> > this case? Something like -Wno-returning-noreturn. I'm >> interested in >> > > adding >> > > >> > this myself if it's not convenient for gcc's maintainers to do >> so at >> > > the >> > > >> > moment, but I'd need some guidance on where to look and what the >> > > relevant >> > > >> > code is >> > > >> >> > > >> You could just add >> > > >> __builtin_unreachable(); (or std::unreachable(); if you are C++23 >> or >> > > >> unreachable() if you are using C23). >> > > >> Or even add while(true) ; >> > > >> >> > > >> I am pretty sure not having an option is on purpose and not really >> > > >> interested in adding an option here because of the above >> workarounds. >> > > >> >> > > >> Thanks, >> > > >> Andrew Pinski >> > > >> >> > > >> > >> > > >> > best regards, >> > > >> > Julian >> > > >> > --00000000000045806c05ffbd4335--