#484: CCTK_CHECK_C_INLINE can define away the inline keyword ---------------------+------------------------------------------------------ Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Resolution: | Keywords: ---------------------+------------------------------------------------------
Comment (by rhaas):
Thank you.
Hmm, "lets me compile" was not really very clear, yes. Sorry.
The previous version compiled with the PGI compiler. It #defined "inline" to the empty string. So the only inlining happening was due to the optimizer deciding that a given is a good function to inline. All the inline hints were lost (since, as you correctly pointed out, inlining is always the choice of the compiler, it does not have to do anything at all when it sees an "inline" statement). I would have to run speed tests to check if PGI's compiler is smart enough to inline all the functions we want to be inlined even if all "inline" keywords were removed.
Using the previous version, gcc 4.6, and no further options I could not compile (actually link) because of the strsep_3c errors (nor can i now I think). I can and could compile/link using gcc 4.6 by either switching the CCTK_C_INLINE check back to the old AC_INLINE check or by using -fgnu89-inline. So right now I can compile and am reasonably happy (on Kraken I will likely use AC_INLINE to keep the "inline" hints present until/if-not I find a way to change PGI's inline semantics to gnu89).
Compilation seems to fail (or be possible to fail) since the gnu89 and c99 semantics for "inline" differ in how visible "inline" functions are. The issue with gcc 4.6 was that its compiler specific string2.h file checks for the inline flavor used by looking at __GNUC_STDC_INLINE__. If we redefine inline then this check fails (since __GNUC_STDC_INLINE__ is true but inline actually behaves like gnu89) which causes string2.h to make the inline functions visible to the linker which in turn causes link time errors.