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 <[email protected]>
CC: Thomas Gleixner <[email protected]>
CC: Ingo Molnar <[email protected]>
CC: "H. Peter Anvin" <[email protected]>
CC: [email protected]
CC: [email protected]
CC: [email protected]
CC: Martin Schwidefsky <[email protected]>
CC: Heiko Carstens <[email protected]>
CC: [email protected]
CC: [email protected]
CC: David Howells <[email protected]>
CC: Koichi Yasutake <[email protected]>
CC: [email protected]
CC: Kyle McMartin <[email protected]>
CC: Helge Deller <[email protected]>
CC: [email protected]
CC: Benjamin Herrenschmidt <[email protected]>
CC: Paul Mackerras <[email protected]>
CC: [email protected]
CC: Richard Henderson <[email protected]>
CC: Ivan Kokshaysky <[email protected]>
CC: [email protected]
CC: Haavard Skinnemoen <[email protected]>
CC: Mike Frysinger <[email protected]>
CC: [email protected]
---
include/linux/compiler-gcc4.h | 14 ++++++++++++++
include/linux/compiler.h | 5 +++++
2 files changed, 19 insertions(+), 0 deletions(-)
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; \
--
1.6.2.5
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)
? :)
--
Greetings, Michael.
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<[email protected]> 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 -- [email protected]
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<[email protected]> 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