Re: False ???noreturn??? function does return warnings

[Jan Hubicka <hubicka at ucw dot cz>]

> 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