Re: Raising our compiler requirements for 9.6

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Raising our compiler requirements for 9.6
Date: 2015-08-06 07:09:02
Message-ID: 20150806070902.GE12214@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-08-05 23:18:08 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > ... I'm going to reshuffle things in that direction tomorrow. I'll
> > wait for other fallout first though. So far only gcc, xlc and clang (via
> > gcc frontend) have run...
>
> In the department of "other fallout", pademelon is not happy:
>
> cc -Ae -g +O0 -Wp,-H16384 -I../../../src/include -D_XOPEN_SOURCE_EXTENDED -I/usr/local/libxml2-2.6.23/include/libxml2 -I/usr/local/include -c -o pg_resetxlog.o pg_resetxlog.c
> cc -Ae -g +O0 -Wp,-H16384 pg_resetxlog.o -L../../../src/port -L../../../src/common -L/usr/local/libxml2-2.6.23/lib -L/usr/local/lib -Wl,+b -Wl,'/home/bfarm/bf-data/HEAD/inst/lib' -Wl,-z -lpgcommon -lpgport -lxnet -lxml2 -lz -lreadline -ltermcap -lm -o pg_resetxlog
> /usr/ccs/bin/ld: Unsatisfied symbols:
> pg_atomic_clear_flag_impl (code)
> pg_atomic_init_flag_impl (code)
> pg_atomic_compare_exchange_u32_impl (code)
> pg_atomic_fetch_add_u32_impl (code)
> pg_atomic_test_set_flag_impl (code)
> pg_atomic_init_u32_impl (code)
> make[3]: *** [pg_resetxlog] Error 1
>
> I'd have thought that port/atomics.c would be included in libpgport, but
> it seems not.

Given that it requires spinlocks for the fallback, which in turn may
require semaphores, that didn't seem like a good idea. Thus atomics.c is
in src/backend/port not src/port (just like other locking stuff like
spinlocks, semaphores etc).

> (But is pademelon really the only buildfarm critter relying
> on the "fallback" atomics implementation?)

I don't think so. At least that didn't use to be the case. My guess is
that less ancient compilers don't emit code for unreferenced functions
and this thus doesn't show up.

> Another possible angle is: what the heck does pg_resetxlog need with
> atomic ops, anyway?

It really doesn't. It's just fallout from indirectly including lwlock.h
which includes an atomic variable. The include path leading to it is

In file included from /home/andres/src/postgresql/src/include/storage/lwlock.h:19:0,
from /home/andres/src/postgresql/src/include/storage/lock.h:18,
from /home/andres/src/postgresql/src/include/access/tuptoaster.h:18,
from /home/andres/src/postgresql/src/bin/pg_resetxlog/pg_resetxlog.c:49:
/home/andres/src/postgresql/src/include/port/atomics.h:41:2: error: #error "THOU SHALL NOT REQUIRE ATOMICS"
#error "THOU SHALL NOT REQUIRE ATOMICS"

There's other path's (slot.h) as well if that were fixed.

> Should these things have a different, stub implementation for FRONTEND
> code?

I'm honestly not yet sure what the best approach here would be.

One approach is to avoid including lwlock.h/slot.h in frontend
code. That'll require some minor surgery and adding a couple includes,
but it doesn't look that bad.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-08-06 08:37:32 Re: raw output from copy
Previous Message Mikko Tiihonen 2015-08-06 07:02:10 Re: [PATCH] libpq: Allow specifying multiple host names to try to connect to