Broken atomics code on PPC with FreeBSD 10.3

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