On 06.02.2012 13:24, Heikki Linnakangas wrote:
> On 03.02.2012 02:48, Bruce Momjian wrote:
>> Sorry for the late reply, but Heikki, can you get this Itanium
>> information into s_lock.h as a comment, particularly the information
>> about the +Ovolatile=__unordered flag?
>
> Good idea. I came up with the attached, hope that explains it.
Committed these additional comments.
> Looking back at the discussions, we concluded that the current code is
> safe on gcc, because it implicitly adds the .rel/.acq opcodes to
> volatile accesses, and HP's compiler does the same as long as you don't
> explicitly disable it with +Ovolatile=__unordered. But what about
> Intel's icc compiler? Presumably it's also safe, but looking at Intel's
> manuals that I found, I'm not completely sure about it. There's an
> option, -m[no-]serialize-volatile, that controls it, but I couldn't
> figure out which is the default. Looking at the docs on that from Intel
> that I found [1], it seems to me that on Linux, the default is *not*
> safe, but on Windows it is.
>
> Sergey, you have dugong in the buildfarm that uses Intel's compiler on
> Itanium. Could you verify whether the -mno-serialize-volatile is the
> default? If you could for example extract the assembler code generated
> by icc for xlog.c, and send it over. Whether it's generating the
> .rel/.acq opcodes should be easy to see in the generated code of the
> XLogGetLastRemoved() function, for example, which doesn't do much else
> than grab a spinlock. On gcc, the -s flag generates the assembly files,
> I presume it's the same on icc.
Sergey confirmed off-list that icc defaults to -mserialize-volatile, so
we're safe.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com