[Please ignore the previous incomplete version of this reply, which I
sent by mistake. Sorry for the list noise.]
On 12/15/2009 2:09 PM, Marko Kreen wrote:>> Oh. Ok then. Force-inline seems better fix as we may want to use> it for
otherreasons too (converting big macros).>> So it seems like a good moment to solve it for gcc too.
Is ordinary inlining not sufficient?
If deluxe inlining is something that might be wanted in the
future, but isn't needed right now, perhaps we should wait
until then.
> Your worry ii) can be ignored, managing to compile on such> compilers is already overachievement.
I think so too. With your opinion added to mine, do we constitute a
consensus of the pg community? Someone might object that a sample of
two individuals is insufficiently representative of the whole, but
away with the pedants: let us not quibble over trifles.
> The question is now what should we put into configure and what into> headers.
PostgreSQL seems mostly to follow the GNU tradition of using
autoconf rather than thickets of #ifdefs to discover platform
characteristics such as supported features, variant spellings of
keywords and identifiers, and the like. This often makes it easier
to support new platforms, assuming the autoconf mechanism is
understood.
Autoconf facilitates testing directly for the needed features:
generally a better approach than hard-coding knowledge of the
peculiarities of particular compilers, compiler release levels,
instruction set architectures, etc. For example, instead of
writing #ifdefs to decide, "if this is gcc, and the version is
high enough, then __funcname__ should work", it's better to let
autoconf actually try to compile a program using __funcname__.
That way PostgreSQL can keep up with the evolution of improved
and new compilers without continually updating an #ifdef-encoded
knowledge base of compiler capabilities.
> Simplest would be to have plain AC_C_INLINE in configure> and then in header (c.h?):>> #ifdef _MSC_VER> #undef
inline>#define inline __forceinline> #else> #ifdef __GNUC__> #undef inline> #define inline inline
__attribute__((always_inline))>#endif> #endif>> (Not compile tested :)
This would force every inline. Why do we want that?
For gcc, I think the __attribute__ has to come after the function's
parameter list, rather than before the return type.
> Or should we put that logic also into configure,> so that the config.h already contains proper 'inline'?
That's how it works at present for plain (not forced) inline.
Regards,
... kurt
