Re: Raising our compiler requirements for 9.6

On Sun, Aug 16, 2015 at 02:03:01AM +0200, Andres Freund wrote:
> On 2015-08-15 12:47:09 -0400, Noah Misch wrote:
> > $ make -s PROFILE='-O0 -DPG_FORCE_DISABLE_INLINE=1'
> > pg_resetxlog.o: In function `fastgetattr':
> > /data/nmisch/src/pg/postgresql/src/bin/pg_resetxlog/../../../src/include/access/htup_details.h:754: undefined reference to `nocachegetattr'
> > pg_resetxlog.o: In function `heap_getattr':
> > /data/nmisch/src/pg/postgresql/src/bin/pg_resetxlog/../../../src/include/access/htup_details.h:783: undefined reference to `heap_getsysattr'

> What's the advantage of using STATIC_IF_INLINE over just #ifndef
> FRONTEND?

> In fact STATIC_IF_INLINE does *not* even help here unless we also detect
> compilers that support inlining but balk when inline functions reference
> symbols not available. There was an example of that in the buildfarm as
> of 2014, c.f. a9baeb361d63 . We'd have to disable inlining for such
> compilers.

Neat; I didn't know that. Solaris Studio 12.3 (newest version as of Oct 2014)
still does that when optimization is disabled, and I place sufficient value on
keeping inlining enabled for such a new compiler. The policy would then be
(already is?) to wrap in "#ifdef FRONTEND" any inline function that uses a
backend symbol. When a header is dedicated to such functions, we might avoid
the whole header in the frontend instead of wrapping each function. That
policy works for me.

On Sat, Aug 15, 2015 at 01:48:17PM -0400, Tom Lane wrote:
> Realistically, with what we're doing now, we *have* broken things for
> stupid-about-inlines compilers; because even if everything in the core
> distribution builds, we've almost certainly created failures for
> third-party modules that need to #include headers that no contrib
> module includes.

Only FRONTEND code (e.g. repmgr, pg_reorg) will be at hazard, not ordinary
third-party (backend) modules. We could have a test frontend that includes
every header minus a blacklist, but I don't think it's essential. External
FRONTEND code is an order of magnitude less common than external backend code.
Unlike backend module development, we don't document the existence of the
FRONTEND programming environment.