* Allan Sandfeld Jensen: > 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. Ahh, and anonymous namespaces (the equivalent for that for member functions) do not work in such cases because the representation of the class still needs to be shared across API boundaries. With an anonymous namspace, that would be undefined. Thanks, Florian
