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 19722.1439660897@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 August 15, 2015 6:47:09 PM GMT+02:00, Noah Misch <noah@leadboat.com> wrote:
>> That gave me new respect for STATIC_IF_INLINE.  While it does add
>> tedious work to the task of introducing a new batch of inline
>> functions, the work is completely mechanical.  Anyone can write it;
>> anyone can review it; there's one correct way to write it.  Header
>> surgery like
>> 0001-Don-t-include-low-level-locking-code-from-frontend-c.patch
>> requires expert design from scratch, and it (trivially) breaks builds
>> for a sample of non-core code.  Let's return to STATIC_IF_INLINE and
>> convert fastgetattr() therewith.  (A possible future line of inquiry is
>> to generate the STATIC_IF_INLINE transformation at build time, so the
>> handwritten headers can use C99 inlining directly as though it is
>> always available.)

> I'll respond in detail later. But wouldn't it be easy in this case to
> just ifndef FRONTEND things in this case?

I think that's missing Noah's point.  Yeah, we'll probably always be able
to hack things to continue to work, but the key word there is "hack".
And if we don't have buildfarm coverage for compilers that are stupid
about inlining, we can expect to break the case regularly.  (pademelon
won't last forever, though maybe by the time that box dies we'll figure
we no longer need to care about such compilers.)

I'm not especially in love with STATIC_IF_INLINE, but it did offer a
mechanical if tedious solution.

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.

Maybe we should just say "okay, we're raising the bar for 9.6: compilers
that don't elide unused static inlines need not apply".  But I'd be
happier if we had a clear idea which those were.  And if we go that route,
we ought to add a configure test checking it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Raising our compiler requirements for 9.6
Next
From: Tom Lane
Date:
Subject: Re: Small improvement to get_base_rel_indexes()