https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66122
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Denis Vlasenko from comment #8) > If you try to reproduce this with kernel build, be sure to not select > CONFIG_OPTIMIZE_INLINING (it forces inlining by making all iniline functions > __always_inline). > > I didn't mention it before, but the recent (as of this writing) gcc 5.1.1 > 20150422 (Red Hat 5.1.1-1) with -Os easily triggers this behavior (more than > a thousand *.o modules with spurious deinlines during kernel build). If you expect that all functions with inline keyword must be always inlined, then you really should use __always_inline__ attribute. Otherwise, inline keyword is primarily an optimization hint to the compiler that it might be desirable to inline it. So, talking about uninlining or deinlining makes absolutely no sense, the compiler either chooses to inline a function, or doesn't, based on some heuristics, command line options etc. For -Os, not inlining a function declared with inline keyword is often the right thing to do. And as Richard said, you can always look at the dump file to see why something hasn't been inlined.
