Re: Re: [PATCHES] s_lock.h cleanup - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [PATCHES] s_lock.h cleanup
Date
Msg-id 9599.979930166@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [PATCHES] s_lock.h cleanup  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Re: [PATCHES] s_lock.h cleanup  (Larry Rosenman <ler@lerctr.org>)
Re: Re: [PATCHES] s_lock.h cleanup  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> And they may all be broken, except for the one(s) you have tested.
>> You shouldn't be assuming that a platform that uses gcc necessarily
>> also uses gas.

> I can tell you that they all used __asm__, and all used the colon
> terminators for each __asm__ block:

>  *  __asm__ __volatile__(
>  *          "command;"
>  *          "command;"
>  *          "command;"
>  *      :   "=r"(_res)          return value, in register
>  *      :   "r"(lock)           argument, 'lock pointer', in register
>  *      :   "r0");              inline code uses this register

The __asm___ and splitting up the assembly code into multiple string
literals and the consistent formatting of the register addendums are
all fine, because those are read by gcc and this whole code block is
gcc-only.  But the assembly code string literal will be spit out
essentially verbatim by gcc to the assembler, and the assembler may
not be nearly as forgiving as you think.

> Oh, wow, I never suspected gcc could work without gas.  Can it?

Gcc with platform-specific as used to be the standard configuration
on HPUX, and may still be standard on some platforms.

Bottom line: I see no point in taking any risks, especially not this
late in beta, with code that you cannot test for yourself, and
*especially* not when the change is only for cosmetic reasons.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Re: [PATCHES] s_lock.h cleanup
Next
From: Tom Lane
Date:
Subject: Re: Re: Problems with BLOBs under Windows?