Re: Raising our compiler requirements for 9.6 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Raising our compiler requirements for 9.6
Date
Msg-id 29130.1439743744@sss.pgh.pa.us
Whole thread Raw
In response to Re: Raising our compiler requirements for 9.6  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2015-08-15 23:50:09 -0400, Noah Misch wrote:
>> 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.

Yeah.  If we get to the point where we can't actually find any toolchains
that work that way, it may be time to revise our portability policy.  But
for now Solaris Studio is a good-enough reason to not move the goalposts.

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

Works for me as well, as long as we have buildfarm critters that will
notice oversights.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Test code is worth the space
Next
From: Noah Misch
Date:
Subject: Re: TAP tests are badly named