Skip site navigation (1) Skip section navigation (2)

Broken atomics code on PPC with FreeBSD 10.3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Broken atomics code on PPC with FreeBSD 10.3
Date: 2016-12-30 05:44:33
Message-ID: 25414.1483076673@sss.pgh.pa.us (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackers
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


Responses

pgsql-hackers by date

Next:From: Regina ObeDate: 2016-12-30 05:51:56
Subject: What is "index returned tuples in wrong order" for recheck supposed to guard against?
Previous:From: Michael PaquierDate: 2016-12-30 05:41:58
Subject: Re: Support for pg_receivexlog --format=plain|tar

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group