[PATCH] Porting small OpenBSD changes.

David CARLIER <devnexen@gmail.com> writes:

- Reducing OpenBSD postfgresql maintainer internal changes bookeeping if
those small changes make sense for the PostgreSQL developers.

Hm. The s_lock.c change is surely fine if OpenBSD maintainers say it is.

Not sure about adding Motorola 88K support to s_lock.h ... is anybody
really still interested in that platform? OTOH, we still have M68K
and VAX stanzas in that file, so I suppose it's silly to complain
about 88K. A bigger issue is that I wonder whether that code has
ever been tested: it does not look to me like the __asm__ call is
even syntactically correct. There should be colons in it.

regards, tom lane

On 20 November 2017 at 18:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:

David CARLIER <devnexen@gmail.com> writes:

- Reducing OpenBSD postfgresql maintainer internal changes bookeeping if
those small changes make sense for the PostgreSQL developers.

Hm. The s_lock.c change is surely fine if OpenBSD maintainers say it is.

Not sure about adding Motorola 88K support to s_lock.h ... is anybody
really still interested in that platform?

Yes there is :-)

OTOH, we still have M68K
and VAX stanzas in that file, so I suppose it's silly to complain
about 88K. A bigger issue is that I wonder whether that code has
ever been tested: it does not look to me like the __asm__ call is
even syntactically correct. There should be colons in it.

True :-) corrected. Thanks.

On Mon, Nov 20, 2017 at 06:57:47PM +0000, David CARLIER wrote:

On 20 November 2017 at 18:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:

David CARLIER <devnexen@gmail.com> writes:

- Reducing OpenBSD postfgresql maintainer internal changes bookeeping if
those small changes make sense for the PostgreSQL developers.

Hm. The s_lock.c change is surely fine if OpenBSD maintainers say it is.

Not sure about adding Motorola 88K support to s_lock.h ... is anybody
really still interested in that platform?

Yes there is :-)

Any chance of a buildfarm http://www.pgbuildfarm.org/ member or two
with this architecture?

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

David CARLIER <devnexen@gmail.com> writes:

On 20 November 2017 at 18:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:

OTOH, we still have M68K
and VAX stanzas in that file, so I suppose it's silly to complain
about 88K. A bigger issue is that I wonder whether that code has
ever been tested: it does not look to me like the __asm__ call is
even syntactically correct. There should be colons in it.

True :-) corrected. Thanks.

I still dare to doubt whether you've tested this, because AFAICS
the operand numbering is wrong. The "r"(lock) operand is number 3
given these operand declarations, not number 2.

Our practice elsewhere in s_lock.h is to use a "+" constraint instead of
duplicated operands, and I think that's better style because it avoids any
question of whether you're supposed to count duplicated operands.

Also, per the comment near s_lock.h line 115, it's important to specify
"+m"(*lock) as an output operand so that gcc knows that the asm
clobbers *lock. It's possible that "memory" makes that redundant,
but I'd just as soon maintain consistency with the well-tested
other parts of the file.

So I propose the attached patch instead. It would still be a good idea
to actually test this ;-)

regards, tom lane

I wrote:

I still dare to doubt whether you've tested this, because AFAICS
the operand numbering is wrong. The "r"(lock) operand is number 3
given these operand declarations, not number 2.

Oh, my apologies, scratch that. Evidently I put in the "+m"(*lock)
operand and confused myself about what was what.

I still think the form I proposed is better style though.

regards, tom lane

I m not against, I would go with your final version too. Thanks !

On 20 November 2017 at 22:36, Tom Lane <tgl@sss.pgh.pa.us> wrote:

David CARLIER <devnexen@gmail.com> writes:

I m not against, I would go with your final version too. Thanks !

Pushed to all supported branches.

regards, tom lane