I am using C99
under GCC
.
I have a function declared static
inline
in a header that I cannot modify.
The function never returns but is not marked __attribute__((noreturn))
.
How can I call the function in a way that tells the compiler it will not return?
I am calling it from my own noreturn function, and partly want to suppress the "noreturn function returns" warning but also want to help the optimizer etc.
I have tried including a declaration with the attribute but get a warning about the repeated declaration.
I have tried creating a function pointer and applying the attribute to that, but it says the function attribute cannot apply to a pointed function.
The __attribute__ directive is used to decorate a code declaration in C, C++ and Objective-C programming languages. This gives the declared code additional attributes that would help the compiler incorporate optimizations or elicit useful warnings to the consumer of that code.
You can use the __builtin_expect built-in function to indicate that an expression is likely to evaluate to a specified value. The compiler can use this knowledge to direct optimizations. This built-in function is portable with the GNU C/C++ __builtin_expect function.
The purpose of __builtin_unreachable is to help the compiler to: Remove dead code (that programmer knows will never be executed) Linearize the code by letting compiler know that the path is "cold" (similar effect is achieved by calling noreturn function)
This function returns the return address of the current function, or of one of its callers. The level argument is number of frames to scan up the call stack. A value of 0 yields the return address of the current function, a value of 1 yields the return address of the caller of the current function, and so forth.
From the function you defined, and which calls the external function, add a call to __builtin_unreachable
which is built into at least GCC and Clang compilers and is marked noreturn
. In fact, this function does nothing else and should not be called. It's only here so that the compiler can infer that program execution will stop at this point.
static inline external_function() // lacks the noreturn attribute { /* does not return */ } __attribute__((noreturn)) void your_function() { external_function(); // the compiler thinks execution may continue ... __builtin_unreachable(); // ... and now it knows it won't go beyond here }
Edit: Just to clarify a few points raised in the comments, and generally give a bit of context:
__attribute__((noreturn))
is an annotation (like const
) which is a way for the programmer to inform the compiler that he's absolutely sure a function will not return. Following the trust but verify principle, the compiler tries to prove that the function does indeed not return. If may then issue an error if it proves the function may return, or a warning if it was not able to prove whether the function returns or not.__builtin_unreachable
has undefined behaviour because it is not meant to be called. It's only meant to help the compiler's static analysis. Indeed the compiler knows that this function does not return, so any following code is provably unreachable (except through a jump).Once the compiler has established (either by itself, or with the programmer's help) that some code is unreachable, it may use this information to do optimizations like these:
__builtin_unreachable()
is unreachable.noreturn
. That's what happens for your_function
.pure
functions) may be removed.Illustration:
external_function
cannot be removed because it might have side-effects. In fact, it probably has at least the side effect of terminating the process!your_function
may be removedHere's another example showing how code before the unreachable point may be removed
int compute(int) __attribute((pure)) { return /* expensive compute */ } if(condition) { int x = compute(input); // (1) no side effect => keep if x is used // (8) x is not used => remove printf("hello "); // (2) reachable + side effect => keep your_function(); // (3) reachable + side effect => keep // (4) unreachable beyond this point printf("word!\n"); // (5) unreachable => remove printf("%d\n", x); // (6) unreachable => remove // (7) mark 'x' as unused } else { // follows unreachable code, but can jump here // from reachable code, so this is reachable do_stuff(); // keep }
Several solutions:
__attribute__
You should try to modify that function in its header by adding __attribute__((noreturn))
to it.
You can redeclare some functions with new attribute, as this stupid test demonstrates (adding an attribute to fopen
) :
#include <stdio.h> extern FILE *fopen (const char *__restrict __filename, const char *__restrict __modes) __attribute__ ((warning ("fopen is used"))); void show_map_without_care (void) { FILE *f = fopen ("/proc/self/maps", "r"); do { char lin[64]; fgets (lin, sizeof (lin), f); fputs (lin, stdout); } while (!feof (f)); fclose (f); }
At last, you could define a macro like
#define func(A) {func(A); __builtin_unreachable();}
(this uses the fact that inside a macro, the macro name is not macro-expanded).
If your never-returning func
is declaring as returning e.g. int
you'll use a statement expression like
#define func(A) ({func(A); __builtin_unreachable(); (int)0; })
Macro-based solutions like above won't always work, e.g. if func
is passed as a function pointer, or simply if some guy codes (func)(1)
which is legal but ugly.
noreturn
attributeAnd the following example:
// file ex.c // declare exit without any standard header void exit (int); // define myexit as a static inline static inline void myexit (int c) { exit (c); } // redeclare it as notreturn static inline void myexit (int c) __attribute__ ((noreturn)); int foo (int *p) { if (!p) myexit (1); if (p) return *p + 2; return 0; }
when compiled with GCC 4.9 (from Debian/Sid/x86-64) as gcc -S -fverbose-asm -O2 ex.c
) gives an assembly file containing the expected optimization:
.type foo, @function foo: .LFB1: .cfi_startproc testq %rdi, %rdi # p je .L5 #, movl (%rdi), %eax # *p_2(D), *p_2(D) addl $2, %eax #, D.1768 ret .L5: pushq %rax # .cfi_def_cfa_offset 16 movb $1, %dil #, call exit # .cfi_endproc .LFE1: .size foo, .-foo
You could play with #pragma GCC diagnostic to selectively disable a warning.
Finally, you could customize your recent gcc
using the MELT plugin and coding your simple extension (in the MELT domain specific language) to add the attribute noreturn
when encoutering the desired function. It is probably a dozen of MELT lines, using register_finish_decl_first
and a match on the function name.
Since I am the main author of MELT (free software GPLv3+) I could perhaps even code that for you if you ask, e.g. here or preferably on [email protected]
; give the concrete name of your never-returning function.
Probably the MELT code is looking like:
;;file your_melt_mode.melt (module_is_gpl_compatible "GPLv3+") (defun my_finish_decl (decl) (let ( (tdecl (unbox :tree decl)) ) (match tdecl (?(tree_function_decl_named ?(tree_identifier ?(cstring_same "your_function_name"))) ;;; code to add the noreturn attribute ;;; .... )))) (register_finish_decl_first my_finish_decl)
The real MELT code is slightly more complex. You want to define your_adding_attr_mode
there. Ask me for more.
Once you coded your MELT extension your_melt_mode.melt
for your needs (and compiled that MELT extension into your_melt_mode.quicklybuilt.so
as documented in the MELT tutorials) you'll compile your code with
gcc -fplugin=melt \ -fplugin-arg-melt-extra=your_melt_mode.quicklybuilt \ -fplugin-arg-melt-mode=your_adding_attr_mode \ -O2 -I/your/include -c yourfile.c
In other words, you just add a few -fplugin-*
flags to your CFLAGS
in your Makefile
!
BTW, I'm just coding in the MELT monitor (on github: https://github.com/bstarynk/melt-monitor ..., file meltmom-process.melt
something quite similar.
With a MELT extension, you won't get any additional warning, since the MELT extension would alter the internal GCC AST (a GCC Tree) of the declared function on the fly!
Customizing GCC with MELT is probably the most bullet-proof solution, since it is modifying the GCC internal AST. Of course, it is probably the most costly solution (and it is GCC specific and might need -small- changes when GCC is evolving, e.g. when using the next version of GCC), but as I am trying to show it is quite easy in your case.
PS. In 2019, GCC MELT is an abandoned project. If you want to customize GCC (for any recent version of GCC, e.g. GCC 7, 8, or 9), you need to write your own GCC plugin in C++.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With