Re: Call for port reports

Peter Eisentraut <peter_e@gmx.net> writes:
> HP-UX hpunix5 B.11.00 U 9000/803 2002765023

> Using the system compiler, I get several complaints about our use of
> "inline", for example:

Interesting.  CVS tip works fine for me on HPUX 10.20, using cc -Ae.
It looks like configure deduces inline is not supported on this
compiler, though:

/* Define as `__inline' if that's what the C compiler calls it, or to nothing
   if it is not supported. */
#define inline 

What do you get on that compiler?

> I had to patch it as follows to get it to work:

Odd.  I count ten inline functions in the backend:

src/backend/storage/lmgr/lock.c: 94: inline static bool
src/backend/storage/lmgr/lock.c: 105: inline static void
src/backend/storage/lmgr/lock.c: 126: inline static void
src/backend/storage/lmgr/lwlock.c: 67: inline static void
src/backend/storage/lmgr/lwlock.c: 77: inline static void
src/backend/utils/adt/pg_lzcompress.c: 389: static inline int
src/backend/utils/hash/dynahash.c: 465: static inline uint32
src/backend/utils/mmgr/aset.c: 256: static inline int
src/backend/utils/sort/tuplesort.c: 1787: static inline Datum
src/backend/utils/sort/tuplesort.c: 1819: static inline int32

Why would only three of them fail?

I'm not eager to remove the inlining optimization for everyone just
because this one compiler fails.  I think a more reasonable approach
would be to force inline to be #define'd as empty on that platform.
Or file a bug report with HP.

			regards, tom lane