gcc implements speculative devirtualisation of virtual functions (https://stackoverflow.com/questions/37888728/inlining-of-virtual-functions-clang-vs-gcc). The aim is to avoid an indirect virtual call if it can spot that it is the base implementation.
There are a couple of problems with this though:
- If the object is defined in a different dll/so from the call then it will almost certainly fail. (Since the inline function will be regenerated rather than exported from the dll).
- It adds ~ 16bytes and a few cycles to each function call that doesn't match the default.
- It is very confusing looking at the generated assembler!
My conclusion is that if you have an interface that is called between dll/so you should not include a default inline implementation (unless there is a really good reason.) The helper classes in eclhelper are good examples which should be fixed. Should also look at some of the other key interfaces (e.g., IFileDescriptor + others)