Andres Freund <and...@2ndquadrant.com> writes: > On 2015-01-10 18:40:58 -0500, Tom Lane wrote: >> Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers