Re: s_lock.h default definitions are rather confused

Andres Freund <andres@2ndquadrant.com> writes:
> On 2015-01-10 18:40:58 -0500, Tom Lane wrote:
>> Andres Freund <andres@2ndquadrant.com> writes:
>>> Actually. It looks like I only translated the logic from barrier.h 1:1
>>> and it already was broken there. Hm, it looks like the current code
>>> essentially is from 89779bf2c8f9aa480e0ceb8883f93e9d65c43a6e.

>> There's a small difference, which is that the code actually worked as
>> of that commit.

> Are you sure it actually worked on hppa && !gcc? Sure, the s_lock.h gcc
> breakage is caused by Robert's s_lock.h commit (making spinlock proper
> barriers), but I don't see how the tree as of 89779bf2c8f9aa48 could
> work on !gcc hppa?

Ah, sorry, I mixed up commit hashes.  I can say that the !gcc HPPA build
worked as of commit 44cd47c1d49655c5dd9648bde8e267617c3735b4, instead.
I don't think I'd tried it since then, until yesterday.

> Could you check whether that heals that problem? I've verified that it
> allows me to build with gcc, even if I remove its compiler barrier
> definition.

As of HEAD right now, the !gcc build is fine (well, there are a few
warnings that have been there for awhile, but they're uninteresting).
The gcc build is still spewing lots of

../../../../src/include/storage/s_lock.h:759: warning: `S_UNLOCK' redefined
../../../../src/include/storage/s_lock.h:679: warning: this is the location of the previous definition
        regards, tom lane