[Top] [All Lists]

Re: [PATCH] MIPS: Make BUG() __noreturn.

To: Geert Uytterhoeven <>
Subject: Re: [PATCH] MIPS: Make BUG() __noreturn.
From: "Maciej W. Rozycki" <>
Date: Fri, 21 Nov 2008 11:14:30 +0000 (GMT)
Cc: Alan Cox <>, David Daney <>, linux-mips <>,
In-reply-to: <Pine.LNX.4.64.0811211126420.26004@anakin>
Original-recipient: rfc822;
References: <> <> <Pine.LNX.4.64.0811211126420.26004@anakin>
User-agent: Alpine 1.10 (LFD 962 2008-03-14)
On Fri, 21 Nov 2008, Geert Uytterhoeven wrote:

> > That sounds like your __noreturn macro is wrong.
> > 
> > Try using __attribute__ ((__noreturn__))
> > 
> > if that works then fix up the __noreturn definitions for the MIPS and gcc
> > you have.
> Nope, gcc is too smart:
> $ cat a.c
> int f(void) __attribute__((__noreturn__));
> int f(void)
> {
> }
> $ gcc -c -Wall a.c
> a.c: In function f:
> a.c:6: warning: `noreturn' function does return
> $ 

 Hmm, in the case of your example the warning is justified, because the 
(virtual) "return" statement of your function is in a unconditional block.  
Otherwise it looks like the attribute is useless -- it looks like it can 
only be used for functions where GCC can determine the function does not 
return anyway.  Which means it is redundant.

 The cases where within the function concerned there is a volatile asm or 
a conditional block which cannot be determined with simple static analysis 
that it does stop look like legitimate ones for the use of the "noreturn" 
attribute and my opinion is GCC should not warn about them with -Wall, 
though a separate -W<whatever> option for the inquisitive would make sense 
to me.  It might be worthwhile to have a look into archives of the GCC 
mailing lists to see how the implementation has evolved into the current 
form and if no useful conclusion can be made, to bring the issue now 
and/or file a bug report.


<Prev in Thread] Current Thread [Next in Thread>