> In an OS kernel functions that do not return are commonly used and
> practically always their code is beyond gcc's ability to recognize
> noreturn functions. A typical example would for example be the BUG()
> function in Linux which is implemented as something like:
>
> static inline void __attribute__((noreturn)) BUG(void)
> {
> __asm__ __volatile__("trap");
> }
>
> So the code doesn't return but gcc isn't able to figure that out and the
> caring programmer trying to help gcc to do a better job by adding the
Well, sadly caring programmer won't get optimization he wants as after
inlining this attribute information becomes completely lost.
What about __builtin_trap?
It results in int 6 that might not be applicable, but adding some
control over it to i386 backend is definitly an option.
> noreturn is punished with
>
> warning: ???noreturn??? function does return
>
> There are other such situations in plain C. A common solution is to add
> something like like while(1) - but that does generate code. Quite a bit
> for frequently called or very small functions. This frequently makes the
> use of noreturn functions unattractive. So two suggested solutions:
>
> 1) Burry the warning for good. The programmer has explicitly said
> noreturn so if the function does return it's his problem.
>
> 2) Introduce a __builtin_unreached() builtin function which tells gcc that
> it not being reached, ever and does not generate any code. This could
> be used like:
>
> static inline void __attribute__((noreturn)) BUG(void)
> {
> __asm__ __volatile__("trap");
> __builtin_unreached();
This is bit dificult to do in general since it introduces new kind of
control flow construct. It would be better to express such functions
explicitely to GCC.
Honza
> }
>
> It would even conveniently be usable in macros or conditionals.
>
> Ralf
