Re: xlc atomics

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: xlc atomics
Дата
Msg-id 20150705000749.GA902950@tornado.leadboat.com
обсуждение исходный текст
Ответ на Re: xlc atomics  (Andres Freund <andres@anarazel.de>)
Ответы Re: xlc atomics  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Sun, Jul 05, 2015 at 12:54:43AM +0200, Andres Freund wrote:
> On 2015-07-04 18:40:41 -0400, Noah Misch wrote:
> > (1) "IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72)".  Getting it working
> > required the attached patch.

> Will you apply? Having the ability to test change seems to put you in a
> much better spot then me.

I will.

> > (2) "IBM XL C/C++ for Linux, V13.1.2 (5725-C73, 5765-J08)" for ppc64le,
> > http://www-01.ibm.com/support/docview.wss?uid=swg27044056&aid=1.  This
> > compiler has a Clang-derived C frontend.  It defines __GNUC__ and offers
> > GCC-style __sync_* atomics.
>
> Phew. I don't see much reason to try to support this. Why would that be
> interesting?
>
> > Therefore, PostgreSQL selects generic-gcc.h.
> > test_atomic_ops() fails because __sync_lock_test_and_set() of one-byte types
> > segfaults at runtime.  I have reported this to the vendor.  Adding
> > "pgac_cv_gcc_sync_char_tas=no" to the "configure" invocation is a good
> > workaround.  I could add a comment about that to src/test/regress/sql/lock.sql
> > for affected folks to see in regression.diffs.  To do better, we could make
> > PGAC_HAVE_GCC__SYNC_CHAR_TAS perform a runtime test where possible.  Yet
> > another option is to force use of generic-xlc.h on this compiler.
>
> It seems fair enough to simply add another test and include
> generic-xlc.h in that case. If it's indeed xlc, why not?

Works for me.  I'll do that as attached.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: xlc atomics
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: Let PostgreSQL's On Schedule checkpoint write buffer smooth spread cycle by tuning IsCheckpointOnSchedule?