From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marko Kreen <markokr(at)gmail(dot)com> |
Cc: | Kurt Harriman <harriman(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Patch: Remove gcc dependency in definition of inline functions |
Date: | 2009-12-16 14:50:53 |
Message-ID: | 3171.1260975053@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Marko Kreen <markokr(at)gmail(dot)com> writes:
> On 12/16/09, Kurt Harriman <harriman(at)acm(dot)org> wrote:
>> For gcc, I think the __attribute__ has to come after the function's
>> parameter list, rather than before the return type.
> No.
[ squint... ] That's nowhere documented that I can find: all the
examples in the gcc docs show __attribute__ after the parameters.
It does seem to work, but should we rely on it?
The bigger problem though is that not all versions of gcc understand
always_inline:
$ gcc -Wall check.c
check.c:3: warning: `always_inline' attribute directive ignored
which I think is sufficient reason to put an end to this sub-thread.
We have no particular need for force-inline semantics anyway, as
long as the compiler behaves reasonably for unreferenced inlines,
which gcc always has.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-12-16 14:55:57 | Re: Range types |
Previous Message | Robert Haas | 2009-12-16 14:45:30 | Re: idea - new aggregates median, listagg |