On Sun, Aug 16, 2015 at 05:58:17AM +0200, Andres Freund wrote: > 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.
> > 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. I would just make a "gcc -O0 -DPG_FORCE_DISABLE_INLINE=1" animal, since the Solaris machine time supply is small. > > 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? +1. Most coding rules go undocumented, but I'm in favor of changing that as the opportunity arises. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
