Hi, On 2016-12-30 00:44:33 -0500, Tom Lane wrote: > *** /usr/home/tgl/pgsql/src/test/regress/expected/lock.out Thu Dec 29 > 19:37:50 2016 > --- /usr/home/tgl/pgsql/src/test/regress/results/lock.out Fri Dec 30 > 00:31:01 2016 > *************** > *** 63,70 **** > -- atomic ops tests > RESET search_path; > SELECT test_atomic_ops(); > ! test_atomic_ops > ! ----------------- > ! t > ! (1 row) > ! > --- 63,66 ---- > -- atomic ops tests > RESET search_path; > SELECT test_atomic_ops(); > ! ERROR: flag: set spuriously #2 > > ======================================================================
Hm, not good. > After some digging I found out that the atomics code appears to believe > that the PPC platform has byte-wide atomics, which of course is nonsense. > That causes it to define pg_atomic_flag with the "char" variant, and > what we end up with is word-wide operations (lwarx and friends) operating > on a byte-wide struct. Failure is not exactly astonishing; what's > surprising is that we don't get stack-clobber core dumps or such. > Undef'ing HAVE_GCC__SYNC_CHAR_TAS makes it work. > > Perhaps it could be argued that there's a FreeBSD compiler bug here, > but what I'm wondering is why configure believes that this: > > [char lock = 0; > __sync_lock_test_and_set(&lock, 1); > __sync_lock_release(&lock);])], > > is going to draw a hard error on platforms without byte-wide atomics. > My sense of C semantics is that the best you could hope for is a > warning Well, in theory these aren't actual functions but intrinsics with special behaviour ("by being overloaded so that they work on multiple types."). The compiler is supposed to warn and link to an external function if a certain operation is not available: Not all operations are supported by all target processors. If a particular operation cannot be implemented on the target processor, a warning is generated and a call to an external function is generated. The external function carries the same name as the built-in version, with an additional suffix ā_nā where n is the size of the data type. So that assumption made in that configure test doesn't seem that unreasonable. What assembler do byte-wide atomics generate on that platform? Which compiler/version is this? Regards, Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers