Re: Patch: Remove gcc dependency in definition of inline functions

Kurt Harriman <harriman@acm.org>

From: Kurt Harriman <harriman@acm.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Date: 2010-01-19T03:40:49Z
Lists: pgsql-hackers
On 1/18/2010 4:42 PM, Tom Lane wrote:
 > Kurt Harriman<harriman@acm.org>  writes:
 >>     c) Use configure to automate the testing of each build environment
 >>        in situ.
 >
 >> The third alternative adapts to new or little-known platforms
 >> with little or no manual intervention.
 >
 > This argument is bogus unless you can demonstrate a working configure
 > probe for the property in question.  The question about this patch,
 > from day one, has been whether we have a working configure test.

It does work to detect almost exactly the desired property:
the absence of a compiler or linker warning when a static
inline function is defined but not referenced.

"Almost" exactly, because rather than absence of errors or
warnings, the exact condition tested is: successful exit
code and nothing whatever written to stdout or stderr.
(That is a built-in feature of autoconf.)

Its success is easily demonstrated on any platform by editing the
code within AC_LINK_PROGRAM to induce a compiler or linker warning.

 >> It is true that configure doesn't need to test for MSVC's
 >> __forceinline keyword.  I included that mainly as a placeholder
 >> for the benefit of future hackers:  likely someone will
 >> discover a need for a special keyword to suppress another
 >> compiler's warnings.
 >
 > I think including MSVC in the set of compilers targeted by a configure
 > test is just a waste of code.  It's more likely to confuse people than
 > help them.

There's a loop for trying a series of compiler-specific
formulas.  The list contains two items:  (1) "inline" or
equivalent as determined by AC_C_INLINE; (2) __forceinline.
In a 2-item list, it is easy to see the syntax for adding a
third item: in this case, the language is 'sh' and the list
is space-separated.  The code is:

     for pgac_kw in "$ac_cv_c_inline" "__forceinline" ; do
       AC_LINK_IFELSE([AC_LANG_PROGRAM([static $pgac_kw int fun () {return 0;}],[])],
                      [pgac_cv_c_hushinline=$pgac_kw])
       test "$pgac_cv_c_hushinline" != no && break
     done

MSVC __forceinline could be dropped from the list:

     for pgac_kw in "$ac_cv_c_inline" ; do
       AC_LINK_IFELSE([AC_LANG_PROGRAM([static $pgac_kw int fun () {return 0;}],[])],
                      [pgac_cv_c_hushinline=$pgac_kw])
       test "$pgac_cv_c_hushinline" != no && break
     done

Since the list would then have only one element, the
whole loop could be dropped.

     AC_LINK_IFELSE([AC_LANG_PROGRAM([static $pgac_kw int fun () {return 0;}],[])],
                      [pgac_cv_c_hushinline=$pgac_kw])

Someone could reinstate the loop if it is discovered that MSVC
is not the only compiler which needs something special to
silence its unused-function warning.

Regards,
... kurt