| Message ID | 1252627011-2933-1-git-send-email-ddaney@caviumnetworks.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On 09/10/2009 04:56 PM, David Daney wrote: > +#ifndef unreachable > +# define unreachable() do { for (;;) ; } while (0) > +#endif #define unreachable() do { } while (1) r~
On Friday 11 September 2009 01:56:42 David Daney wrote: > +/* Unreachable code */ > +#ifndef unreachable > +# define unreachable() do { for (;;) ; } while (0) > +#endif # define unreachable() do { } while (1) ? :)
Michael Buesch wrote: > On Friday 11 September 2009 01:56:42 David Daney wrote: >> +/* Unreachable code */ >> +#ifndef unreachable >> +# define unreachable() do { for (;;) ; } while (0) >> +#endif > > # define unreachable() do { } while (1) > > ? :) Clearly I was not thinking clearly when I wrote that part. RTH noted the same thing. I will fix it. Thanks, David Daney
On Fri, Sep 11, 2009 at 17:58, David Daney<ddaney@caviumnetworks.com> wrote: > Michael Buesch wrote: >> >> On Friday 11 September 2009 01:56:42 David Daney wrote: >>> >>> +/* Unreachable code */ >>> +#ifndef unreachable >>> +# define unreachable() do { for (;;) ; } while (0) >>> +#endif >> >> # define unreachable() do { } while (1) >> >> ? :) > > Clearly I was not thinking clearly when I wrote that part. RTH noted the > same thing. I will fix it. However, people are so used to seeing the `do { } while (0)' idiom, that they might miss there's a `1' here, not a `0'. So perhaps it's better to use plain `for (;;)' for infinite loops? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Geert Uytterhoeven wrote: > On Fri, Sep 11, 2009 at 17:58, David Daney<ddaney@caviumnetworks.com> wrote: >> Michael Buesch wrote: >>> On Friday 11 September 2009 01:56:42 David Daney wrote: >>>> +/* Unreachable code */ >>>> +#ifndef unreachable >>>> +# define unreachable() do { for (;;) ; } while (0) >>>> +#endif >>> # define unreachable() do { } while (1) >>> >>> ? :) >> Clearly I was not thinking clearly when I wrote that part. RTH noted the >> same thing. I will fix it. > > However, people are so used to seeing the `do { } while (0)' idiom, > that they might miss > there's a `1' here, not a `0'. > > So perhaps it's better to use plain `for (;;)' for infinite loops? > I don't think so. The only valid token that can follow 'do { } while (1)' is ';', any statement may follow 'for (;;)', so there is a greater possibility to silently screw things up with the for(;;) form. David Daney
diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h index 450fa59..ab3af40 100644 --- a/include/linux/compiler-gcc4.h +++ b/include/linux/compiler-gcc4.h @@ -36,4 +36,18 @@ the kernel context */ #define __cold __attribute__((__cold__)) + +#if __GNUC_MINOR__ >= 5 +/* + * Mark a position in code as unreachable. This can be used to + * suppress control flow warnings after asm blocks that transfer + * control elsewhere. + * + * Early snapshots of gcc 4.5 don't support this and we can't detect + * this in the preprocessor, but we can live with this because they're + * unreleased. Really, we need to have autoconf for the kernel. + */ +#define unreachable() __builtin_unreachable() +#endif + #endif diff --git a/include/linux/compiler.h b/include/linux/compiler.h index 04fb513..7efd73f 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -144,6 +144,11 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect); # define barrier() __memory_barrier() #endif +/* Unreachable code */ +#ifndef unreachable +# define unreachable() do { for (;;) ; } while (0) +#endif + #ifndef RELOC_HIDE # define RELOC_HIDE(ptr, off) \ ({ unsigned long __ptr; \
Starting with version 4.5, GCC has a new built-in function __builtin_unreachable() that can be used in places like the kernel's BUG() where inline assembly is used to transfer control flow. This eliminated the need for an endless loop in these places. The patch adds a new macro 'unreachable()' that will expand to either __builtin_unreachable() or an endless loop depending on the compiler version. Signed-off-by: David Daney <ddaney@caviumnetworks.com> CC: Thomas Gleixner <tglx@linutronix.de> CC: Ingo Molnar <mingo@redhat.com> CC: "H. Peter Anvin" <hpa@zytor.com> CC: x86@kernel.org CC: ralf@linux-mips.org CC: linux-mips@linux-mips.org CC: Martin Schwidefsky <schwidefsky@de.ibm.com> CC: Heiko Carstens <heiko.carstens@de.ibm.com> CC: linux390@de.ibm.com CC: linux-s390@vger.kernel.org CC: David Howells <dhowells@redhat.com> CC: Koichi Yasutake <yasutake.koichi@jp.panasonic.com> CC: linux-am33-list@redhat.com CC: Kyle McMartin <kyle@mcmartin.ca> CC: Helge Deller <deller@gmx.de> CC: linux-parisc@vger.kernel.org CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: Paul Mackerras <paulus@samba.org> CC: linuxppc-dev@ozlabs.org CC: Richard Henderson <rth@twiddle.net> CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru> CC: linux-alpha@vger.kernel.org CC: Haavard Skinnemoen <hskinnemoen@atmel.com> CC: Mike Frysinger <vapier@gentoo.org> CC: uclinux-dist-devel@blackfin.uclinux.org --- include/linux/compiler-gcc4.h | 14 ++++++++++++++ include/linux/compiler.h | 5 +++++ 2 files changed, 19 insertions(+), 0 deletions(-)