public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	David Daney <ddaney@caviumnetworks.com>,
	linux-mips <linux-mips@linux-mips.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MIPS: Make BUG() __noreturn.
Date: Fri, 21 Nov 2008 11:14:30 +0000 (GMT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0811211059290.20023@ftp.linux-mips.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0811211126420.26004@anakin>

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.

  Maciej

  reply	other threads:[~2008-11-21 11:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-21  1:26 [PATCH] MIPS: Make BUG() __noreturn David Daney
2008-11-21 10:00 ` Alan Cox
2008-11-21 10:27   ` Geert Uytterhoeven
2008-11-21 11:14     ` Maciej W. Rozycki [this message]
2008-11-21 12:58       ` Andreas Schwab
2008-11-21 16:40     ` David Daney
2008-11-21 18:46       ` Geert Uytterhoeven
2008-11-21 22:16         ` Ralf Baechle
2008-11-24 19:04           ` Maciej W. Rozycki
2008-11-21 23:00 ` Andrew Morton
2008-11-21 23:48   ` David Daney
2008-11-23  9:58   ` Ingo Molnar
2008-11-24  9:20     ` Ralf Baechle
2008-11-25  0:16     ` Jeremy Fitzhardinge
2008-11-22  9:39 ` Ralf Baechle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.1.10.0811211059290.20023@ftp.linux-mips.org \
    --to=macro@linux-mips.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=ddaney@caviumnetworks.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox