Re: [Boost-users] [signals2][variant] inline warning with MSVC 2022

From: John Maddock (jz.maddock_at_[hidden])
Date: 2022-09-23 17:01:17

> __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.