Re: (Modified) Patch request for PostgreSQL 7.4 for HP-UX IA-64 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: (Modified) Patch request for PostgreSQL 7.4 for HP-UX IA-64
Date
Msg-id 8592.1072220522@sss.pgh.pa.us
Whole thread Raw
In response to (Modified) Patch request for PostgreSQL 7.4 for HP-UX IA-64  ("ViSolve Open Source Team" <opensrc_support_hp@visolve.com>)
List pgsql-bugs
"ViSolve Open Source Team" <opensrc_support_hp@visolve.com> writes:
> this is a modified and more focussed patch request for PostgreSQL for for H=
> P-UX
> 11i V2  for the Intel Itanium architecture  (known to the PostgreSQL code as
> IA-64).=20

I looked into applying the TAS part of this patch now that Bruce has
finished revising the TAS code, but I do not believe it is right.
The tas() routine looks reasonable, but not this:

> +#define S_UNLOCK(lock) \
> +  ( \
> +    _Asm_mov_to_ar((_Asm_app_reg)_AREG_CCV, 1UL),\
> +      (_Asm_cmpxchg((_Asm_sz)_SZ_W, _SEM_REL, \
> +                    (volatile slock_t*)lock, \
> +                    0UL, (_Asm_ldhint)_LDHINT_NONE, \
> +                    (_UP_MEM_FENCE|_DOWN_MEM_FENCE)) =3D=3D 1) ? 1 : 0 \
> +    )

In the first place, S_UNLOCK does not return a value.  In the second,
I doubt that you need an xchg instruction at all --- can't you just
assign zero?  (If you can't, then the gcc IA64 code is wrong,
because it uses the default version of S_UNLOCK.)

> +#define S_LOCK_FREE(lock)       ( *(volatile slock_t*)(lock))

This is wrong too, unless you're not using the convention that zero
indicates a free lock.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Kris Jurka
Date:
Subject: Re: BUG #1026: org.apache.commons.dbcp.DbcpException: The
Next
From: "aarjan langereis"
Date:
Subject: Re: BUG #1015: Got a signal 11 while trying to create a temp table