Re: Raising our compiler requirements for 9.6

On 2015-08-15 23:50:09 -0400, Noah Misch wrote:
> 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.

Personally I don't find that particularly neat, rather annoying actually
:P

> 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.

Ah, that's cool. I was wondering generally how we could find an animal
to detect that case once pademelon met its untimely (or timely by now?)
end.

> 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.

Cool. I was wondering before where we'd document policy around
this. sources.sgml?

Greetings,

Andres Freund