Re: Raising our compiler requirements for 9.6
От | Noah Misch |
---|---|
Тема | Re: Raising our compiler requirements for 9.6 |
Дата | |
Msg-id | 20150816043131.GB2069620@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: Raising our compiler requirements for 9.6 (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
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 referenceto `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 referenceto `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.
В списке pgsql-hackers по дате отправления: