Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

2017-01-03 Thread Tom Lane
Robert Haas writes: > The only point I'm making here is that the width of a spinlock is not > irrelevant. Sure, but it does not follow that we need to get all hot and bothered about the width of pg_atomic_flag, which has yet to find its first use-case. When and if its

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

2017-01-03 Thread Robert Haas
On Tue, Jan 3, 2017 at 12:07 PM, Tom Lane wrote: > [ shrug... ] I have not seen you putting any effort into optimizing > slock_t on non-x86 architectures, where it might make a difference today. > Why all the concern about shaving hypothetical future bytes for >

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

2017-01-03 Thread Tom Lane
Robert Haas writes: > On Tue, Jan 3, 2017 at 11:11 AM, Tom Lane wrote: A survey of s_lock.h shows that we prefer char-width slock_t only on these architectures: x86 sparc (but not sparcv9, there we use int) m68k vax

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

2017-01-03 Thread Robert Haas
On Tue, Jan 3, 2017 at 11:11 AM, Tom Lane wrote: >>> A survey of s_lock.h shows that we prefer char-width slock_t only on >>> these architectures: >>> >>> x86 >>> sparc (but not sparcv9, there we use int) >>> m68k >>> vax > >> I don't think that's right, because on my MacBook

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

2017-01-03 Thread Tom Lane
Robert Haas writes: > On Mon, Jan 2, 2017 at 4:04 PM, Tom Lane wrote: >> After further study, I'm inclined to just propose that we flip the default >> width of pg_atomic_flag in generic-gcc.h: use int not char if both are >> available. The only modern

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

2017-01-03 Thread Robert Haas
On Mon, Jan 2, 2017 at 4:04 PM, Tom Lane wrote: > I wrote: >> But that doesn't really detract from my point, which is that it's >> totally silly for us to imagine that char and word-wide atomic ops are >> interchangeable on all platforms and we can flip a coin to decide which

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

2017-01-02 Thread Tom Lane
I wrote: > But that doesn't really detract from my point, which is that it's > totally silly for us to imagine that char and word-wide atomic ops are > interchangeable on all platforms and we can flip a coin to decide which > to use as long as the configure probes don't fail outright. Even given

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

2016-12-30 Thread Tom Lane
Andres Freund writes: > On December 30, 2016 4:48:22 PM GMT+01:00, Tom Lane > wrote: >> and got no warnings and the attached output. I'm not very good at >> reading PPC assembler, but I think what is happening in the "char" case is >> that >> gcc is

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

2016-12-30 Thread Andres Freund
On December 30, 2016 4:48:22 PM GMT+01:00, Tom Lane wrote: >and got no warnings and the attached output. I'm not very good at >reading >PPC assembler, but I think what is happening in the "char" case is that >gcc is trying to emulate a byte-wide operation using a word-wide

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

2016-12-30 Thread Andres Freund
On December 30, 2016 4:48:22 PM GMT+01:00, Tom Lane wrote: >Andres Freund writes: >> On 2016-12-30 00:44:33 -0500, Tom Lane wrote: >>> Perhaps it could be argued that there's a FreeBSD compiler bug here, >>> but what I'm wondering is why configure

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

2016-12-30 Thread Tom Lane
Andres Freund writes: > On 2016-12-30 00:44:33 -0500, Tom Lane wrote: >> 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(, 1); >>

Re: [HACKERS] Broken atomics code on PPC with FreeBSD 10.3

2016-12-30 Thread Andres Freund
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