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
|
Список | 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 по дате отправления: