On Montag, 27. Juli 2020 10:33:35 CEST Florian Weimer wrote: > * Allan Sandfeld Jensen: > > A problem that I keep running into is functions defined headers, but used > > in sources files that are compiled with different CPU feature flags (for > > runtime CPU feature selection). > > > > We know to make sure the functions are inlinable and their address never > > taken, but of course in debug builds they are still not inlined. Every so > > often the functions get compiled using some of the optional CPU > > instructions, and if the linker selects the optimized versions those > > instructions can then leak through to instances compiled with different > > CPU flags where the instructions aren't supposed to be used. This happens > > even in unoptimized debug builds as the extended instruction selections > > doesn't count as an optimization. > > You need to provide source code examples. This isn't supposed to happen > if you declare the functions as static inline. If a function is emitted > for any reason, it will be local this particular object file. > > Plain inline (for C++) works differently and will attempt to share > implementations. > static inline? Hadn't thought of that in a shared header file.
Is harder to do with inline methods in C++ classes though. A recent example I hit into was methods using a qfloat16 class that specializes for F16C when available, see https://codereview.qt-project.org/c/ qt/qtbase/+/307772. Which I guess ought to be split into different classes with different constructors, so they don't violate ODR rules to be really safe across compilers. But I guess a case like https://codereview.qt-project.org/c/qt/qtbase/+/308163 could be solved with static inline instead. Best regards Allan