In pursuit of knowledge about clock_gettime(), I installed FreeBSD 10.3
on a PowerBook I had laying about. I was disappointed to find out that
HEAD fails regression tests on that platform:
*** /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
======================================================================
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
--- and a look at the config.log on this platform says we're not
even getting that.
In short, I'd put the blame here on a ridiculously optimistic configure
check.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
