On Fri, Feb 12, 2010 at 9:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 10, 2010 at 5:53 PM, Kurt Harriman wrote:
>>> Revised patch is attached (4th edition).
>
>> This looks generally sane to me, though it seems entirely imaginable
>> that it might break something, somewhere, for
Robert Haas writes:
> On Wed, Feb 10, 2010 at 5:53 PM, Kurt Harriman wrote:
>> Revised patch is attached (4th edition).
> This looks generally sane to me, though it seems entirely imaginable
> that it might break something, somewhere, for somebody... in which
> case I suppose we'll adjust as nee
On Wed, Feb 10, 2010 at 6:04 PM, Kurt Harriman wrote:
> By the way, suggestions which must be carried out without
> question are "orders", not "advice". When a statement,
> meant to be imperative, is phrased softly as advice, it can
> easily be mistaken as optional by newcomers who may not have
>
On Wed, Feb 10, 2010 at 5:53 PM, Kurt Harriman wrote:
> Revised patch is attached (4th edition).
This looks generally sane to me, though it seems entirely imaginable
that it might break something, somewhere, for somebody... in which
case I suppose we'll adjust as needed.
Peter, are you planning
On 2/10/2010 7:12 AM, Tom Lane wrote:
Kurt, you seem to be more or less impervious to advice :-(.
Thank you for reviewing my patch. It is a rare honor to
have my personal qualities reviewed here as well.
Since this forum is archived for posterity, I suppose I
must point out that I have in fac
Kurt Harriman writes:
> On 1/19/2010 8:01 AM, Peter Eisentraut wrote:
>> One principle that I suppose should have been made more explicit is that
>> -- in my mind -- we should avoid littering our code with nonstandard
>> constructs in place of standard constructs.
> Everyone seems to hate the nam
On 12/16/2009 8:21 AM, Tom Lane wrote:
I would only suggest that the cleanest coding would be
#ifdef USE_INLINE
static inline foo(...) ...
#else
... non-inline definition of foo
#endif
ie, go ahead and rely on autoconf's definition (if any) of "inline
On 12/16/2009 8:40 AM, Tom Lane wrote:
Alvaro Herrera writes:
IIRC Kurt was also on about getting rid of some ugly macros that could
instead be coded as inline functions (fastgetattr for example)
I'd just bounce that as useless activity. If they are macros now,
and work, the only possible ef
On 1/19/2010 8:01 AM, Peter Eisentraut wrote:
On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote:
On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
We have some existing inline functions in .c files. These can be
more complicated, so it might be ok if the compiler decides to
leave them out-of-
On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
On mån, 2010-01-18 at 16:34 -0800, Kurt Harriman wrote:
MSVC does warn about unused static inline functions. The warning
is prevented by using __forceinline instead of __inline.
Hmm, but forceinline is not the same as inline. Are we confident th
On 1/18/2010 4:42 PM, Tom Lane wrote:
I think including MSVC in the set of compilers targeted by a configure
test is just a waste of code. It's more likely to confuse people than
help them.
Ok, I have taken that out, and instead put the right stuff for MSVC into
pg_config.h.win32.
Regards, ..
On Tue, Jan 19, 2010 at 4:55 PM, Kurt Harriman wrote:
> I'll submit an updated patch.
We need this patch pretty soon if we're going to include this in 9.0, I think.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
On 1/19/2010 8:43 AM, Tom Lane wrote:
Peter Eisentraut writes:
On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote:
Or compiler switches could be set to disable all such warnings
globally. Warning 4514 is specific to inline functions; so
maybe it would be alright to keep it turned off glob
Peter Eisentraut writes:
> On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote:
>> Or compiler switches could be set to disable all such warnings
>> globally. Warning 4514 is specific to inline functions; so
>> maybe it would be alright to keep it turned off globally.
> ... I think that would
On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote:
> On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
> We have some existing inline functions in .c files. These can be
> more complicated, so it might be ok if the compiler decides to
> leave them out-of-line. And they are never unreferenced, s
On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
On mån, 2010-01-18 at 16:34 -0800, Kurt Harriman wrote:
MSVC does warn about unused static inline functions. The warning
is prevented by using __forceinline instead of __inline.
Hmm, but forceinline is not the same as inline. Are we confident th
On 1/17/2010 11:27 AM, Peter Eisentraut wrote:
I have found an Autoconf macro that checks whether the compiler properly
supports C99 inline semantics. This would allow us to replace the
__GNUC__ conditional with HAVE_C99_INLINE, in this case.
At present, PostgreSQL uses only "static inline", w
On mån, 2010-01-18 at 16:34 -0800, Kurt Harriman wrote:
> MSVC does warn about unused static inline functions. The warning
> is prevented by using __forceinline instead of __inline.
Hmm, but forceinline is not the same as inline. Are we confident that
forcing inlining is not going to lead to dis
On 1/18/2010 4:42 PM, Tom Lane wrote:
> Kurt Harriman writes:
>> c) Use configure to automate the testing of each build environment
>>in situ.
>
>> The third alternative adapts to new or little-known platforms
>> with little or no manual intervention.
>
> This argument is bogus unless
Kurt Harriman writes:
>c) Use configure to automate the testing of each build environment
> in situ.
> The third alternative adapts to new or little-known platforms
> with little or no manual intervention.
This argument is bogus unless you can demonstrate a working configure
probe for
On 1/18/2010 1:20 PM, Peter Eisentraut wrote:
I seem to recall that somewhere else it was said that MSVC produces
warnings on unused static inline functions. Am I mistaken?
MSVC does warn about unused static inline functions. The warning
is prevented by using __forceinline instead of __inline
On sön, 2009-12-06 at 02:21 -0800, Kurt Harriman wrote:
> > Which ones does it actually offer any benefit for?
>
> MSVC is one.
I seem to recall that somewhere else it was said that MSVC produces
warnings on unused static inline functions. Am I mistaken?
Also, if this is mainly for the benefit
Peter Eisentraut writes:
> I have found an Autoconf macro that checks whether the compiler properly
> supports C99 inline semantics. This would allow us to replace the
> __GNUC__ conditional with HAVE_C99_INLINE, in this case. Interestingly,
> however, this check results in GCC <=4.2 *not* suppo
On ons, 2009-12-16 at 10:49 -0500, Tom Lane wrote:
> I think you're way overthinking this. Where we started was just
> a proposal to try to expand the set of inline-ing compilers beyond
> "gcc only". I don't see why we need to do anything but that. The
> code is fine as-is except for the control
On ons, 2009-12-16 at 10:49 -0500, Tom Lane wrote:
> Marko Kreen writes:
> > So the plain-C89 compilers would be downgraded to "second-class"
> > targets, not worth getting max performance out of them.
>
> Hm? Failing to inline is already a performance hit, which is why
> Kurt got interested in
Alvaro Herrera writes:
> Tom Lane escribió:
>> I think you're way overthinking this. Where we started was just
>> a proposal to try to expand the set of inline-ing compilers beyond
>> "gcc only". I don't see why we need to do anything but that. The
>> code is fine as-is except for the control #
On 12/16/09, Tom Lane wrote:
> Marko Kreen writes:
>
> > So the plain-C89 compilers would be downgraded to "second-class"
> > targets, not worth getting max performance out of them.
>
>
> Hm? Failing to inline is already a performance hit, which is why
> Kurt got interested in this in the fir
Marko Kreen writes:
> On 12/15/09, Kurt Harriman wrote:
>> Attached is a revised patch, offered for the 2010-01 commitfest.
>> It's also available in my git repository in the "submitted" branch:
>>
>> http://git.postgresql.org/gitweb?p=users/harriman/share.git;a=shortlog;h=refs/heads/submitted
Tom Lane escribió:
> I think you're way overthinking this. Where we started was just
> a proposal to try to expand the set of inline-ing compilers beyond
> "gcc only". I don't see why we need to do anything but that. The
> code is fine as-is except for the control #ifdefs.
IIRC Kurt was also o
Marko Kreen writes:
> So the plain-C89 compilers would be downgraded to "second-class"
> targets, not worth getting max performance out of them.
Hm? Failing to inline is already a performance hit, which is why
Kurt got interested in this in the first place.
I think you're way overthinking this.
On 12/16/09, Tom Lane wrote:
> Marko Kreen writes:
> > Hypothetical old, crappy compilers would still work, only AC_C_INLINE
> > would turn "static inline" into plain "static", so hypothetically
> > they would get some warnings about unused functions.
>
> > As this is all hypothetical, I don'
On 12/16/09, Tom Lane wrote:
> Marko Kreen writes:
> > On 12/16/09, Kurt Harriman 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
Marko Kreen writes:
> Hypothetical old, crappy compilers would still work, only AC_C_INLINE
> would turn "static inline" into plain "static", so hypothetically
> they would get some warnings about unused functions.
> As this is all hypothetical, I don't see why that should stop us
> cleaning our
On Wed, Dec 16, 2009 at 9:30 AM, Marko Kreen wrote:
> On 12/16/09, Robert Haas wrote:
>> On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harriman wrote:
>> >> Your worry ii) can be ignored, managing to compile on such
>> >> compilers is already overachievement.
>> >
>> > I think so too. With your op
Marko Kreen writes:
> On 12/16/09, Kurt Harriman 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
On 12/16/09, Robert Haas wrote:
> On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harriman wrote:
> >> Your worry ii) can be ignored, managing to compile on such
> >> compilers is already overachievement.
> >
> > I think so too. With your opinion added to mine, do we constitute a
> > consensus of th
On 12/16/09, Kurt Harriman wrote:
> [Please ignore the previous incomplete version of this reply, which I
> sent by mistake. Sorry for the list noise.]
>
> On 12/15/2009 2:09 PM, Marko Kreen wrote:
> >
> > Oh. Ok then. Force-inline seems better fix as we may want to use
> > it for other re
On 12/15/2009 9:42 PM, Robert Haas wrote:
On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harriman wrote:
Your worry ii) can be ignored, managing to compile on such
compilers is already overachievement.
I think so too. With your opinion added to mine, do we constitute a
consensus of the pg community?
On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harriman wrote:
>> Your worry ii) can be ignored, managing to compile on such
>> compilers is already overachievement.
>
> I think so too. With your opinion added to mine, do we constitute a
> consensus of the pg community? Someone might object that a sampl
[Please ignore the previous incomplete version of this reply, which I
sent by mistake. Sorry for the list noise.]
On 12/15/2009 2:09 PM, Marko Kreen wrote:
>
> Oh. Ok then. Force-inline seems better fix as we may want to use
> it for other reasons too (converting big macros).
>
> So it seems l
On 12/15/2009 2:09 PM, Marko Kreen wrote:
Oh. Ok then. Force-inline seems better fix as we may want to use
it for other reasons too (converting big macros).
So it seems like a good moment to solve it for gcc too.
Is ordinary inlining not sufficient?
If deluxe inlining is something that mig
On 12/15/09, Kurt Harriman wrote:
> On 12/15/2009 1:31 PM, Marko Kreen wrote:
>
> > Do you have actual proof that MSVC launches warnings on unused
> > "static inline" functions? Not "static", but "static inline".
>
> Yes, I tried it, and that's why I did it this way.
Oh. Ok then. Force-inline
On 12/15/2009 1:31 PM, Marko Kreen wrote:
Do you have actual proof that MSVC launches warnings on unused
"static inline" functions? Not "static", but "static inline".
Yes, I tried it, and that's why I did it this way.
If yes, indeed we need to fix it. MSVC is broken then, but it does
not ma
On 12/15/09, Kurt Harriman wrote:
> On 12/15/2009 4:05 AM, Marko Kreen wrote:
> > Unless it is some popular compiler (as "in actual use") it is
> > premature complexity. Please remove that.
>
> Microsoft's compilers are in actual use, and some might even
> say they are popular. For example,
On 12/15/2009 4:05 AM, Marko Kreen wrote:
On 12/15/09, Kurt Harriman wrote:
Attached is a revised patch, offered for the 2010-01 commitfest.
It's also available in my git repository in the "submitted" branch:
http://git.postgresql.org/gitweb?p=users/harriman/share.git;a=shortlog;h=refs/hea
On 12/15/09, Kurt Harriman wrote:
> Attached is a revised patch, offered for the 2010-01 commitfest.
> It's also available in my git repository in the "submitted" branch:
>
> http://git.postgresql.org/gitweb?p=users/harriman/share.git;a=shortlog;h=refs/heads/submitted
>
> In this version, the "
Bruce Momjian wrote:
Peter Eisentraut wrote:
On m?n, 2009-11-30 at 07:06 -0500, Bruce Momjian wrote:
I thought one problem was that inline is a suggestion that the compiler
can ignore, while macros have to be implemented as specified.
Sure, but one could argue that a compiler that doesn't supp
Tom Lane wrote:
Kurt Harriman writes:
(Does anybody still use a C compiler that doesn't support
inline functions?)
The question isn't so much that, it's whether the compiler supports
inline functions with the same behavior as gcc.
With this patch, if the compiler doesn't accept the "inli
On 12/2/09, James Mansion wrote:
> Marko Kreen wrote:
>
> > Note - my proposal would be to get rid of HAVE_INLINE, which
> > means we are already using inline functions unconditionally
> > on platforms that matter (gcc). Keeping duplicate code
> > for obsolete compilers is pointless.
> >
> >
> M
James Mansion writes:
> Marko Kreen wrote:
>> Note - my proposal would be to get rid of HAVE_INLINE, which
>> means we are already using inline functions unconditionally
>> on platforms that matter (gcc). Keeping duplicate code
>> for obsolete compilers is pointless.
> Microsoft C doesn't matter
Marko Kreen wrote:
Note - my proposal would be to get rid of HAVE_INLINE, which
means we are already using inline functions unconditionally
on platforms that matter (gcc). Keeping duplicate code
for obsolete compilers is pointless.
Microsoft C doesn't matter?
I seem to remember that when th
On 11/30/09, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > On m?n, 2009-11-30 at 07:06 -0500, Bruce Momjian wrote:
> > > I thought one problem was that inline is a suggestion that the compiler
> > > can ignore, while macros have to be implemented as specified.
> >
> > Sure, but one could
Peter Eisentraut wrote:
> On m?n, 2009-11-30 at 07:06 -0500, Bruce Momjian wrote:
> > I thought one problem was that inline is a suggestion that the compiler
> > can ignore, while macros have to be implemented as specified.
>
> Sure, but one could argue that a compiler that doesn't support inline
On mån, 2009-11-30 at 07:06 -0500, Bruce Momjian wrote:
> I thought one problem was that inline is a suggestion that the compiler
> can ignore, while macros have to be implemented as specified.
Sure, but one could argue that a compiler that doesn't support inline
usefully is probably not the sort
Marko Kreen wrote:
> On 11/29/09, Tom Lane wrote:
> > Kurt Harriman writes:
> > > (Does anybody still use a C compiler that doesn't support
> > > inline functions?)
>
> +1 for modern C.
>
> > The question isn't so much that, it's whether the compiler supports
> > inline functions with the sa
On 11/29/09, Tom Lane wrote:
> Kurt Harriman writes:
> > (Does anybody still use a C compiler that doesn't support
> > inline functions?)
+1 for modern C.
> The question isn't so much that, it's whether the compiler supports
> inline functions with the same behavior as gcc. At minimum that
Kurt Harriman writes:
> (Does anybody still use a C compiler that doesn't support
> inline functions?)
The question isn't so much that, it's whether the compiler supports
inline functions with the same behavior as gcc. At minimum that
would require
* not generating extra copies of the fu
Hi,
The attached patch is offered for the 2010-01 commitfest.
It's also available in my git repository in the "submitted" branch:
http://git.postgresql.org/gitweb?p=users/harriman/share.git;a=shortlog;h=refs/heads/submitted
In palloc.h and pg_list.h, some inline functions are defined if
allow
58 matches
Mail list logo
