My opinion: don't try to second guess the compiler/optimizer; stop using inline. Full Stop.
On 07/27/2015 01:56 AM, Anoop C S wrote:
Hi all, Due to the recent changes with GCC v5 [default standard is now GNU11], we have been reported with some issues regarding undefined symbol errors from different components. One important change while porting to GCC v5 is with respect to inline functions [see GCC 5 porting changes @https://gcc.gnu.org/gcc-5/porting_to.html] These errors were basically root caused to the wrong usage of inline functions when compiled against GCC v5, which now follows the C99 inline semantics by default [previously it was GNU89 inline semantics]. Most of them were fixed at the earliest so that we don't see such errors in our normal work flow. Latest one was failure to start the volume when glusterfs was compiled in debug mode. This was not seen when compiled in non-debug mode due to the presence of a particular compiler optimization level provided via configure.ac [see detailed discussion @ http://www.gluster.org/pipermail/gluster-devel/2015-July/046211.html]. Inline functions which doesn't require external usage. ------------------------------------------------------ Looking through the code base, we can see considerable instances for inline functions. According to C99 inline rules [ http://www.greenend.org.uk/rjk/tech/inline.html], if we wanted to keep our inline function entirely private to one translation unit, we make it static inline. As of now there are instances where we have failed to do so. It is recommended to have those functions as static inline if we really require those functions to be 'inlined' and can be easily done. Or else we can just remove the inline keyword as a whole. Inline functions which require external usage. ---------------------------------------------- On the other side, we have inline functions defined to be used externally. The current implementation in glusterfs doesn't follow the proper inline semantics for such functions. An inline function must be defined in all files that calls it. According to C99 rules [ http://www.greenend.org.uk/rjk/tech/inline.html], there are two ways to generate such an external definition for inline functions. Apart from defining the inline function in a .h file we need to either declare it as 'extern' exactly once or declare it by omitting 'inline' exactly once. In doing so we can make sure that the compiler sees the definition whenever it is used from multiple files and can be 'inlined' effectively. For us, this correction will require moving definitions out of .c files to .h file. Instead of changing all such instances by a single person, it can be done component-wise. Here also we have the other option of removing the inline keyword as a whole. Overall, we have 3 options: [1] Fix all inline functions according to C99 standard. [2] Fix only those inline functions which doesn't require external linkage and remove inline from those who require external linkage. [3] Remove the inline keyword from functions. Suggestions/comments are mostly welcome. Thanks, --Anoop C S.
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
