From: | Kurt Harriman <harriman(at)acm(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch: Remove gcc dependency in definition of inline functions |
Date: | 2010-01-19 03:40:49 |
Message-ID: | 4B5529C1.7000504@acm.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/18/2010 4:42 PM, Tom Lane wrote:
> Kurt Harriman<harriman(at)acm(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-01-19 04:17:16 | Re: Table size does not include toast size |
Previous Message | Tom Lane | 2010-01-19 03:30:33 | Re: Table size does not include toast size |