Robert Haas <robertmh...@gmail.com> writes: > On Mon, Jun 29, 2015 at 10:32 PM, Andres Freund <and...@anarazel.de> wrote: >> You removed a volatile at the same time, and volatile on IA64 has >> acquire/release semantics.
> Can you explain what you mean by volatile having acquire/release > semantics? I don't see how volatile can create a CPU barrier, but I'm > guessing that it somehow can and that you're about to enlighten me. It's late and I'm tired, but: gcc (and, apparently, icc) treats accesses to volatile-qualified objects as cues to emit .acq or .rel memory ordering qualifiers on IA64 instructions, per the comments in s_lock.h. I have not seen any documentation stating specifically that aCC does the same, but the buildfarm evidence is pretty clear that the 9.4 IA64-non-gcc version of S_UNLOCK worked and the up-to-now-9.5 version does not. So personally, I would be inclined to put back the volatile qualifier, independently of any fooling around with _Asm_double_magic_xyzzy calls. Or to put it differently: where is the evidence that removing the volatile qual is a good idea? 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