Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 10, 2010 at 5:53 PM, Kurt Harriman harri...@acm.org 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
On Fri, Feb 12, 2010 at 9:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 10, 2010 at 5:53 PM, Kurt Harriman harri...@acm.org wrote:
Revised patch is attached (4th edition).
This looks generally sane to me, though it seems entirely imaginable
On Wed, Feb 10, 2010 at 5:53 PM, Kurt Harriman harri...@acm.org 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,
On Wed, Feb 10, 2010 at 6:04 PM, Kurt Harriman harri...@acm.org 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
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 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
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
On 12/16/2009 8:40 AM, Tom Lane wrote:
Alvaro Herreraalvhe...@commandprompt.com 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
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
Kurt Harriman harri...@acm.org 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
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
On Tue, Jan 19, 2010 at 4:55 PM, Kurt Harriman harri...@acm.org 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
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,
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
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, so
Peter Eisentraut pete...@gmx.net 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
On 1/19/2010 8:43 AM, Tom Lane wrote:
Peter Eisentrautpete...@gmx.net 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
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 of
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
Kurt Harriman harri...@acm.org 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
On 1/18/2010 4:42 PM, Tom Lane wrote:
Kurt Harrimanharri...@acm.org 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
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
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
Peter Eisentraut pete...@gmx.net 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
On 12/16/09, Kurt Harriman harri...@acm.org 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
On 12/16/09, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harriman harri...@acm.org 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
Marko Kreen mark...@gmail.com writes:
On 12/16/09, Kurt Harriman harri...@acm.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
On Wed, Dec 16, 2009 at 9:30 AM, Marko Kreen mark...@gmail.com wrote:
On 12/16/09, Robert Haas robertmh...@gmail.com wrote:
On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harriman harri...@acm.org wrote:
Your worry ii) can be ignored, managing to compile on such
compilers is already
Marko Kreen mark...@gmail.com 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
On 12/16/09, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com writes:
On 12/16/09, Kurt Harriman harri...@acm.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... ]
On 12/16/09, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com 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
Marko Kreen mark...@gmail.com 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
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 on
Marko Kreen mark...@gmail.com writes:
On 12/15/09, Kurt Harriman harri...@acm.org wrote:
Attached is a revised patch, offered for the 2010-01 commitfest.
It's also available in my git repository in the submitted branch:
On 12/16/09, Tom Lane t...@sss.pgh.pa.us wrote:
Marko Kreen mark...@gmail.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
On ons, 2009-12-16 at 10:49 -0500, Tom Lane wrote:
Marko Kreen mark...@gmail.com 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
On 12/15/09, Kurt Harriman harri...@acm.org 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
On 12/15/2009 4:05 AM, Marko Kreen wrote:
On 12/15/09, Kurt Harrimanharri...@acm.org wrote:
Attached is a revised patch, offered for the 2010-01 commitfest.
It's also available in my git repository in the submitted branch:
On 12/15/09, Kurt Harriman harri...@acm.org 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
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 matter
On 12/15/09, Kurt Harriman harri...@acm.org 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.
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
[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 like
On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harriman harri...@acm.org 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
On 12/15/2009 9:42 PM, Robert Haas wrote:
On Tue, Dec 15, 2009 at 10:34 PM, Kurt Harrimanharri...@acm.org 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
Tom Lane wrote:
Kurt Harriman harri...@acm.org 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
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
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
James Mansion ja...@mansionfamily.plus.com 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.
On 12/2/09, James Mansion ja...@mansionfamily.plus.com 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
Marko Kreen wrote:
On 11/29/09, Tom Lane t...@sss.pgh.pa.us wrote:
Kurt Harriman harri...@acm.org 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
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
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 11/30/09, Bruce Momjian br...@momjian.us 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
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
Kurt Harriman harri...@acm.org 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
On 11/29/09, Tom Lane t...@sss.pgh.pa.us wrote:
Kurt Harriman harri...@acm.org 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
58 matches
Mail list logo
