17

My version (5.4) of gcc warns about unused static functions, even in a header file when -Wall is used. It doesn't complain if the same functions are defined static inline or simply inline.

For example, the following function in a file unused.h:

static void foo() {}

... when included in a test.cpp file as follows:

#include "unused.h"

Generates the following compiler diagnostic when compiler with -Wall:

In file included from test.cpp:11:0:
unused.h: At global scope:
unused.h:9:13: warning: ‘void foo()’ defined but not used [-Wunused-function]
 static void foo() {}
             ^

It is common practice, as far as I know, to include headers with many utility functions, only a handful of which might be used in any given source file. This behavior means that I get warnings for any functions I don't use which are declared only static.

As a practical matter I can simply change these to static inline to get rid of the warning (or turn off the specific warning entirely, but I do find it useful from time to time), but it seems that large utility functions which won't benefit from inlining1 are more logically declared static2.

As far as I know unused static functions (just like static inline) are simply dropped by gcc when the translation unit is compiled, so they pose no binary size or link-time overhead at all.

Am I missing something here? Is there a good reason that unused static functions are more problematic than static inline?

1 Yes, I'm aware it's a hint only but gcc actually takes the hint in many cases.

2 Or perhaps better, only declared in the header file and defined somewhere else in a .cpp file - but that inhibits header-only use which is sometimes convenient.

BeeOnRope
  • 60,350
  • 16
  • 207
  • 386
  • Do you have an example header we can use to reproduce this problem and test possible solutions? – tadman Nov 28 '17 at 23:41
  • @tadman - updated the question. – BeeOnRope Nov 28 '17 at 23:43
  • Is there any reason why the implementation has to be in the header file? Could you not have a separate stub `.cpp` file with the necessary implementations? The optimizer can decide what to do with them then. It's not clear why this is flagged as `static`. Is it used elsewhere in the header file some how and important enough that it stay local to the file? – tadman Nov 28 '17 at 23:44
  • Why do you declare functions in a header to be static to begin with? Why not just inline? I mean, something that's in a header is not really local to some translation unit to begin with. – Baum mit Augen Nov 28 '17 at 23:45
  • @tadman - because it's convenient to have it in a header file, especially when nothing else in the header file needs corresponding implementation in another file. You can simply include the file in your project and forget about it. Once you have an implementation file you need to move that file into somewhere your build system picks it up, or build a library and link against it, etc. – BeeOnRope Nov 28 '17 at 23:46
  • @BeeOnRope It's just a different sort of annoying. I find people use `inline` as the silver bullet to fix their problems when really the best solution is to back up and evaluate why they're defining code inline in the first place. This tends to bloat your executable with duplicated copies of the same function if they are truly inlined. – tadman Nov 28 '17 at 23:47
  • @BaummitAugen - because (a) `inline` also serves as a hint that the function might be good for inlining, so I prefer `static` for functions that I don't want to hint for inlining (e.g., large or non-performance sensitive functions) and (b) in header files shared with C `inline` alone doesn't work there (sometimes an out-of-line function is required, so it's not header-only, etc). – BeeOnRope Nov 28 '17 at 23:48
  • a) does not apply, compilers rightfully don't care about that "hint" usually (and even when they do, are you sure you got that right better than the compiler?). b) only applies if you are mixing in some language you did not tag. Is your question about compatibility between C and C++? – Baum mit Augen Nov 28 '17 at 23:52
  • 1
    @BaummitAugen - a common misunderstanding (essentially a second-order myth). Compilers can still use it as a hint and `gcc` in its newest version certainly does. Here are two identical functions (changed one constant so they aren't folded together) and [gcc only inlines the one one marked `inline`](https://godbolt.org/g/brbDzx) in an identical calling context). About (b) I'm sorry, I can't stand the flames anymore from tagging a question both C and C++. Because I have a valid reason to use `static` functions that might involve interop with some other language doesn't mean I have to tag it. – BeeOnRope Nov 29 '17 at 00:04
  • 1
    I'd suggest just disabling the "unused function" warning if you have no interest in seeing it – M.M Nov 29 '17 at 00:06
  • @M.M - I do want it, in general. As mentioned above it is usually nice when it applies to a function in a `.cpp` file and in some other cases. For now I'm just adding `inline` to make the functions `static inline` or I can use `__attribute((unused))__` or other `gcc` magic like `#pragma GCC diagnostic ignored "-Wunused-function"` to make it go away on a case-by-case basis. The question is more about _why_ gcc does this and if in particular I'm doing "something wrong" with my `static`-but-not-`inline` functions. – BeeOnRope Nov 29 '17 at 00:08
  • *"a common misunderstanding (essentially a second-order myth)"* Not really. You did not enable `-finline-functions`, neither explicitly nor implicitly through `-O3`, so you are practically operating in "trust me, I know better" mode. You are, in the end, stopping gcc from taking the hint as a hint and mostly force it to treat it as a command instead (for functions that are not "small"). Disinterest about optimization flags does not justify by hand in-code optimization. – Baum mit Augen Nov 29 '17 at 00:12
  • *"I can't stand the flames anymore from tagging a question both C and C++."* If the question is about code that's to be used as both C and C++ for proper reasons, I'll gladly jump to your side in that flame war, universally damming the double-tag is a wrong reflex originating from misguided beginner questions. – Baum mit Augen Nov 29 '17 at 00:16
  • @BaummitAugen - what's your point? gcc does _tons_ of inlining even at `-O2` because various inlining options are active there (without inlining it would generate terrible code for all the "zero cost abstractions" that are prevalent in C++). You can try for yourself: make the function smaller and it will inline it, even without `inline` and at `-O2`. **gcc uses the presence of an `inline` specifier on a function in its inline cost heuristic**. Is that hard to believe? I know it's vogue to say "Duh, compiler ignores inline!!!!" but it's no more true than the claim it is countering. – BeeOnRope Nov 29 '17 at 00:19
  • *"You can try for yourself: make the function smaller and it will inline it, even without inline and at -O2"* Yes, because the docs say so. *"gcc uses the presence of an inline specifier on a function in its inline cost heuristic"* Only if you tell it to. *"Is that hard to believe?"* Nope, but it's apparently easy to believe -O2 and -O3 are some magic black-box commands that just "do the right thing". So my point is: Tell the compiler what you want it to do, and inlining functions is one of the things you shouldn't do by hand. – Baum mit Augen Nov 29 '17 at 00:35
  • 1
    @BaummitAugen - the answer as always is "it depends". The compiler has some advantages when it compiles to code generation decisions and so I do I. When it comes to compiling a small function I'll generate better code than the compiler 95% of the time (ignoring ties) - but the compiler's time is nearly free and mine isn't, so I'm happy to let the compiler generate 99% of my code for me. For the remaining 1% I totally make use of _hints_ like `inline`, `hot`, `cold`, `likely`, `unlikely`, `pure`, etc. We are getting _more_ hints these days, not less. – BeeOnRope Nov 29 '17 at 00:48
  • 2
    More to the point, you made a claim that the compiler simply ignores `inline` and I showed at the mainstream, most commonly used optimization level on the most recent version of `gcc` it plainly does not. That's all I have to do. Showing that that `inline` might not make a difference in some other scenario, with some other compilation flags is totally irrelevant. For my use case, it makes a difference, I showed you actual code, end of story. – BeeOnRope Nov 29 '17 at 00:50
  • You are right that gcc in particular does use the hint under some commonly used setting. I would, however, still disagree to the claim that inline is a useful compiler hint; even for your simple example the not exactly rarely used clang inlines the function anyways. I don't dispute the fact that you can out-perform the compiler from time to time, and granted, it sometimes certainly does matter a lot, but in those cases I think you should be a lot more explicit than a mere addition or omission of the inline keyword. Unless you control both the exact compiler version and flags, but that's rare. – Baum mit Augen Nov 29 '17 at 01:13
  • Also, note that commonly used flags are not necessarily correctly used flags, if that inlining flag matters, you'll have to ensure each supported platform uses the proper flags anyways. – Baum mit Augen Nov 29 '17 at 01:20

2 Answers2

13

The warning is because an unused static function might indicate a logic error: why would you have written such a function if it was never called?

However, it is a common idiom to have static inline functions in a header file. Those functions might only be used by some translation units that include the header. It would be annoying if the compiler gave a warning for a translation unit that didn't happen to use one of the functions.

If you deliberately have an unused static non-inline function, you probably will want to either disable the warning entirely, or use a compiler-specific feature to suppress the warning for that function.

Someone asked, "why would you use static inline anyway?". Well, in new C++ you mostly wouldn't use it. However, in C it is a reasonable thing to do. (This is because static inline means the same thing in ISO C and GNU C; however inline without static behaves differently in ISO C than GNU C, so defaulting to static inline just avoids all those issues with no down-side).

People might use static inline in headers that are to be included from both .c and .cpp files; or perhaps they just carry over that habit from C to C++. In the latter case, IMHO it would be annoying for the compiler to warn about something that, although unnecessary, is not a mistake or a problem either.

M.M
  • 138,810
  • 21
  • 208
  • 365
  • Well I have "written" (or something else wrote) such a function for the same reason that most functions in header files you are never called: you include a header file because you need to call _at least one function_ - but not all of them! It makes sense to warn if you actually wrote a function in a `.cpp` file that you didn't call, but not if you included a header file with various functions. – BeeOnRope Nov 28 '17 at 23:50
  • Why would you define them as static, rather than just inline? –  Nov 28 '17 at 23:51
  • @BeeOnRope The preprocessor combines all the relevant source files into a translation unit before the compiler runs; there's no separation of ".cpp file" and "header" at the point the warnings are being generated. – M.M Nov 28 '17 at 23:51
  • @NeilButterworth - because (a) inline also serves as a hint that the function might be good for inlining, so I prefer static for functions that I don't want to hint for inlining (e.g., large or non-performance sensitive functions) and (b) in header files shared with C inline alone doesn't work there (sometimes an out-of-line function is required, so it's not header-only, etc). Don't get me wrong, the solution is `static inline` but I'm curious if somehow only-`static` functions are some kind of anti-pattern. – BeeOnRope Nov 28 '17 at 23:52
  • @M.M - at a conceptual "compiler 101" level sure, where `cpp` runs as a separate process and leaves no trace, but compilers certainly do know where the source came from (how else to generate debug info, for example) and `clang` for example warns only for unused functions in the actual base `.cpp` file, _not_ in header files (btw it warns for `static inline` functions too, if they are unused and appear in the `.cpp` file). – BeeOnRope Nov 28 '17 at 23:53
  • @Neil Butterworth: In my case in order to "see" these inline functions in profiler, I had to be able to disable inlining. In order to do that I used macro `INLINE_` instead of an explicit keyword `inline`. Normally I'd have `#define INLINE_ inline`, but for profiling builds I'd just define `INLINE_` as an empty macro. Without `static` in header files the compilation would break down. There might be better ways to do this, but that was one way. – AnT stands with Russia Nov 28 '17 at 23:55
  • 1
    @BeeOnRope Fair enough. I expanded my answer to cover Neil Butterworth's point – M.M Nov 28 '17 at 23:57
  • @M.M - you mention that in new C++ you wouldn't use `static inline` - is the more idiomatic thing just `inline` then, or anonymous namespace + `inline` or what? I guess there are still some practical differences between `inline` and `static inline` if you take the address of the function (all pointers to the same `inline` function must compare the same, across translation units, but the opposite is true of `static`, I think). – BeeOnRope Nov 30 '17 at 19:09
  • @BeeOnRope the main purpose of `inline` is to allow code in headers; there's nothing to gain by using `static` there in C++. If you were using it in a .cpp file for the optimization feature then yeah, you could use `static` I guess – M.M Nov 30 '17 at 20:00
-1

For such functions you need to set attribute __attribute__((unused)).

Cool Goose
  • 870
  • 10
  • 16