Re: Broken atomics code on PPC with FreeBSD 10.3

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