From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: s_lock.h default definitions are rather confused |
Date: | 2015-01-11 00:22:01 |
Message-ID: | 20150111002201.GE27519@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-01-10 18:40:58 -0500, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On 2015-01-11 00:06:41 +0100, Andres Freund wrote:
> >> Ick, that one is my failure.
>
> > 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?
At least bgworker.c already used read and write barriers back
then. Those were redefined to a compiler barrier by
/* HPPA doesn't do either read or write reordering */
#define pg_memory_barrier() pg_compiler_barrier()
but barrier.h only provided (back then) compiler barriers for icc, gcc,
ia64 (without a compiler restriction?) and win32. So I don't see how
that could have worked.
On a reread, you even noted "But note this patch only fixes things for
gcc, not for builds with HP's compiler." in the commit message..
Anyway, i've pushed a fix for that to master. For one I'm not yet sure
if it's actually broken in the backbranches (and if we care), for
another the <= 9.4 fix will not have a single file in common anyway.
Any opinion on that?
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.
> > Unless somebody protests I'm going to introduce a generic fallback
> > compiler barrier that's just a extern function.
>
> Seems reasonable to me. An empty external function should do the job
> for any compiler that isn't doing cross-procedural analysis.
And I really doubt any of those that do fail to provide a compiler
barrier...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Karlsson | 2015-01-11 00:36:29 | Re: BRIN range operator class |
Previous Message | Andres Freund | 2015-01-11 00:21:56 | Re: Fwd: Re: make check-world regress failed |