On Tue, Jul 4, 2023 at 6:32 PM Julian Waters <tanksherma...@gmail.com> 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 AM Andrew Pinski <pins...@gmail.com> wrote: >> >> On Tue, Jul 4, 2023 at 5:54 PM 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 specifically 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
