__forceinline does not work in debug builds.
https://godbolt.org/z/v3srxv3sr
OTOH, gcc's always_inline does.
https://godbolt.org/z/97rMTKv9r
As I said, BOOST_FORCEINLINE is not a guarantee that the function will be inlined. It is used as an optional hint. The fact that a certain call was not inlined is not an error, meaning that it is an expected possibility, however unfortunate it is. Which means that the warning is informational at best, and completely useless most of the time. I have not had a case when I wanted to see it, nor have I heard of someone wanting it, therefore I want to disable it.
Now, I see that gcc's always_inline is intended to be stronger than that. However, in practice it showed to be an acceptable alternative to __forceinline - BOOST_FORCEINLINE has been defined like that for decades, and I don't remember anyone having a problem with that.
If anything, there could be a need for a new macro that triggers an error if inlining fails, which is exactly what gcc's always_inline gives. But so far there were no requests for such a macro.
I think that goes too far IMO. Look, I actually think the status quo is correct, we have: * not declared inline, but might still be inlined if the compiler thinks it worth while * declared inline, should probably be inlined but might not be if something has to give. * delared __forceinline, a strong hint that if something has to give in the inlining, it should not be this. I actually think it's up to individual library authors, based on the use context, to decide whether they want to suppress warnings about a forced inline failing or not. Let me give you a concrete example: I recently reworked the Boost.Math complete elliptic integrals based on a paper which claimed to obtain equivalent performance to say std::log from their method. Now that's a big bold claim, to be able to do as good as something that's often a compiler intrinsic. Well it turns out that you can do that, but only if the function is expanded inline, and that only happens if the error handling is very slimline with no branch conditions (a "switch" was OK though). The result was that we could more or less match the claims made in the paper, with error handling (where the original paper had none), but only with careful coding and use of BOOST_FORCE_INLINE. In this case I believe I would want to see warnings about inlining not happening, because that would break our performance promises. BTW the difference between inlining or not is about an order of magnitude, and if you're making gazillions of calls to calculate the motion of your spacecraft ;) that could be important. I do appreciate the obnoxiousness of some of these warnings, but also remember that each new compiler release seems to introduce new warnings, so keeping Boost code warning free is next to impossible IMO (though no less desirable). John.