On 2015-08-27 11:31:44 -0400, Tom Lane wrote:
> Needs a bit of copy-editing in places, but +1 overall.
Heres a slightly expanded version of this. I tried to do some of the
copy-editing, but I'm sure a look from a native speaker won't hurt.
Greetings,
Andres Freund
diff --git
On Wed, Aug 5, 2015 at 03:46:36PM +0200, Andres Freund wrote:
On 2015-08-05 15:08:29 +0200, Andres Freund wrote:
We might later want to change some of the harder to maintain macros to
inline functions, but that seems better done separately.
Here's a conversion for fastgetattr() and
On Wed, Aug 12, 2015 at 04:47:55PM -0400, Robert Haas wrote:
On Wed, Aug 12, 2015 at 4:34 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
Andres didn't mention how big the performance benefit he saw with pgbench
was, but I bet it was barely distinguishible from noise. But that's OK. In
fact,
On Wed, Aug 12, 2015 at 10:40:53PM +0200, Andres Freund wrote:
You might argue that it's nothing we have touched frequently. And you're
right. But I think that's a mistake. We spend far too much time in the
various pieces of code dissembling tuples, and I think at some point
somebody really
On 2015-08-16 05:58:17 +0200, Andres Freund wrote:
On 2015-08-15 23:50:09 -0400, Noah Misch wrote:
The policy would then be
(already is?) to wrap in #ifdef FRONTEND any inline function that uses a
backend symbol. When a header is dedicated to such functions, we might
avoid
the whole
Andres Freund and...@anarazel.de writes:
As Noah I think it'd be good if we, over time, started to document a few
more things one currently have to pick up over time. I'm wondering
whether these should be subsections under a new sect1 ('Code Structure'?
Don't like that much), or all
On Thu, Aug 27, 2015 at 4:31 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That's not yet perfect, but shows what I'm thinking of. Comments?
Needs a bit of copy-editing in places, but +1 overall.
Yeah. I bet there's a lot more useful stuff we could include also,
but everything Andres mentioned is
Robert Haas robertmh...@gmail.com writes:
Yeah. I bet there's a lot more useful stuff we could include also,
but everything Andres mentioned is certainly good to put in there.
Alternatively, some of this stuff could go into a README file instead
of the documentation, but I think we've been
On Thu, Aug 27, 2015 at 11:31:44AM -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
As Noah I think it'd be good if we, over time, started to document a few
more things one currently have to pick up over time. I'm wondering
whether these should be subsections under a new
Tom Lane wrote:
It strikes me that the information in backend/utils/mmgr/README would be
a good candidate to move into the Internals SGML, too. Almost none of
that is stuff you only care about when reading utils/mmgr/.
Completely agreed.
--
Álvaro Herrera
On Mon, Aug 17, 2015 at 12:06:42PM +0200, Andres Freund wrote:
On 2015-08-16 03:31:48 -0400, Noah Misch wrote:
I'd love to make it a #warning intead of an error, but unfortunately
that's not standard C :(
Okay.
Other than that benefit, making headers #error-on-FRONTEND mostly lets
us
On 2015-08-16 03:31:48 -0400, Noah Misch wrote:
As we see from the patches' need to add #include statements to .c files and
from Robert's report of a broken EDB build, this change creates work for
maintainers of non-core code, both backend code (modules) and frontend code
(undocumented, but
On Wed, Jul 1, 2015 at 11:14 AM, Andres Freund and...@anarazel.de wrote:
Hi,
During the 9.5 cycle, and earlier, the topic of increasing our minimum
bar for compilers came up a bunch of times. Specifically whether we
still should continue to use C90 as a baseline.
Minor question: is there any
On 2015-08-17 15:51:33 +0100, Greg Stark wrote:
But I'm not clear from the discussion exactly which compilers we're
thinking of ruling out.
None.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Wed, Jul 1, 2015 at 5:14 PM, Andres Freund and...@anarazel.de wrote:
During the 9.5 cycle, and earlier, the topic of increasing our minimum
bar for compilers came up a bunch of times. Specifically whether we
still should continue to use C90 as a baseline.
I think the time has come to rely
On Sat, Aug 15, 2015 at 8:03 PM, Andres Freund and...@anarazel.de wrote:
That gave me new respect for STATIC_IF_INLINE. While it does add tedious
work
to the task of introducing a new batch of inline functions, the work is
completely mechanical. Anyone can write it; anyone can review it;
On 2015-08-17 12:30:56 -0400, Robert Haas wrote:
As far as I can see, the anticipated benefits of what we're doing here are:
- Get a cleaner separation of frontend and backend headers (this could
also be done independently of STATIC_IF_INLINE, but removing
STATIC_IF_INLINE increases the
On 2015-08-17 12:30:56 -0400, Robert Haas wrote:
- The possibility that may repeatedly break #define FRONTEND
compilation when we add static inline functions, where instead adding
macros would not have caused breakage, thus resulting in continual
tinkering with the header files.
Again, that's
On Mon, Aug 17, 2015 at 12:36 PM, Andres Freund and...@anarazel.de wrote:
On 2015-08-17 12:30:56 -0400, Robert Haas wrote:
- The possibility that may repeatedly break #define FRONTEND
compilation when we add static inline functions, where instead adding
macros would not have caused breakage,
On Fri, Aug 14, 2015 at 08:40:13PM +0200, Andres Freund wrote:
On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
+ * lockdefs.h
+ * Frontend exposed parts of postgres' low level lock mechanism
I actually think the split came out to work far better than I'd
anticipated.
Andres Freund and...@anarazel.de writes:
On 2015-08-15 23:50:09 -0400, Noah Misch wrote:
Solaris Studio 12.3 (newest version as of Oct 2014) still does that
when optimization is disabled, and I place sufficient value on keeping
inlining enabled for such a new compiler.
Ah, that's cool. I was
On 2015-08-15 12:47:09 -0400, Noah Misch wrote:
Atomics were a miner's canary for pademelon's trouble with post-de6fd1c
inlining. Expect pademelon to break whenever a frontend-included file gains
an inline function that calls a backend function. Atomics were the initial
examples, but this
On 2015-08-15 23:50:09 -0400, Noah Misch wrote:
On Sun, Aug 16, 2015 at 02:03:01AM +0200, Andres Freund wrote:
On 2015-08-15 12:47:09 -0400, Noah Misch wrote:
$ make -s PROFILE='-O0 -DPG_FORCE_DISABLE_INLINE=1'
pg_resetxlog.o: In function `fastgetattr':
On Sun, Aug 16, 2015 at 02:03:01AM +0200, Andres Freund wrote:
On 2015-08-15 12:47:09 -0400, Noah Misch wrote:
$ make -s PROFILE='-O0 -DPG_FORCE_DISABLE_INLINE=1'
pg_resetxlog.o: In function `fastgetattr':
On Sun, Aug 16, 2015 at 05:58:17AM +0200, Andres Freund wrote:
On 2015-08-15 23:50:09 -0400, Noah Misch wrote:
On Sun, Aug 16, 2015 at 02:03:01AM +0200, Andres Freund wrote:
On 2015-08-15 12:47:09 -0400, Noah Misch wrote:
$ make -s PROFILE='-O0 -DPG_FORCE_DISABLE_INLINE=1'
Andres Freund and...@anarazel.de writes:
On August 15, 2015 6:47:09 PM GMT+02:00, Noah Misch n...@leadboat.com wrote:
That gave me new respect for STATIC_IF_INLINE. While it does add
tedious work to the task of introducing a new batch of inline
functions, the work is completely mechanical.
On August 15, 2015 6:47:09 PM GMT+02:00, Noah Misch n...@leadboat.com wrote:
On Tue, Aug 11, 2015 at 01:04:48PM +0200, Andres Freund wrote:
On 2015-08-05 15:46:36 +0200, Andres Freund wrote:
Here's a conversion for fastgetattr() and heap_getattr().
In my opinion this drastically increases
On Tue, Aug 11, 2015 at 01:04:48PM +0200, Andres Freund wrote:
On 2015-08-05 15:46:36 +0200, Andres Freund wrote:
Here's a conversion for fastgetattr() and heap_getattr().
In my opinion this drastically increases readability and thus should be
applied.
Atomics were a miner's canary for
Hi,
On 2015-08-06 12:43:06 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
Ah, but that's because you cheated and didn't remove the include from
namespace.h ...
Well, it's not included from frontend code, so I didn't see the
On Fri, Aug 14, 2015 at 2:40 PM, Andres Freund and...@anarazel.de wrote:
To pick up on the general discussion and on the points you made here:
I actually think the split came out to work far better than I'd
anticipated. Having a slimmed-down version of lock.h for code that just
needs to
On Wed, Aug 12, 2015 at 4:34 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
Andres didn't mention how big the performance benefit he saw with pgbench
was, but I bet it was barely distinguishible from noise. But that's OK. In
fact, there's no reason to believe this would make any difference to
On Wed, Aug 12, 2015 at 1:34 PM, Heikki Linnakangas hlinn...@iki.fi wrote:
Andres didn't mention how big the performance benefit he saw with pgbench
was, but I bet it was barely distinguishible from noise. But that's OK. In
fact, there's no reason to believe this would make any difference to
On Wed, Aug 12, 2015 at 2:57 PM, Andres Freund and...@anarazel.de wrote:
The only actual separate patch since then (fastgetattr as inline
function) was posted 2015-08-05 and I yesterday suggested to push it
today. And it's just replacing two existing macros by inline functions.
I'm a little
On 08/12/2015 11:25 PM, Robert Haas wrote:
On Wed, Aug 12, 2015 at 2:57 PM, Andres Freund and...@anarazel.de wrote:
The only actual separate patch since then (fastgetattr as inline
function) was posted 2015-08-05 and I yesterday suggested to push it
today. And it's just replacing two existing
On 2015-08-12 16:25:17 -0400, Robert Haas wrote:
On Wed, Aug 12, 2015 at 2:57 PM, Andres Freund and...@anarazel.de wrote:
The only actual separate patch since then (fastgetattr as inline
function) was posted 2015-08-05 and I yesterday suggested to push it
today. And it's just replacing two
On 2015-08-12 23:34:38 +0300, Heikki Linnakangas wrote:
Andres didn't mention how big the performance benefit he saw with pgbench
was, but I bet it was barely distinguishible from noise.
I think it was discernible (I played around with changing unrelated code
trying to exclude unrelated layout
On 2015-08-08 02:30:44 -0400, Noah Misch wrote:
On Sat, Aug 08, 2015 at 02:30:47AM +0200, Andres Freund wrote:
On 2015-08-07 20:16:20 -0400, Noah Misch wrote:
I agree that lock.h offers little to frontend code. Headers that the
lockdefs.h patch made usable in the frontend, particularly
On 2015-08-11 22:34:40 -0400, Noah Misch wrote:
On Tue, Aug 11, 2015 at 01:04:48PM +0200, Andres Freund wrote:
On 2015-08-05 15:46:36 +0200, Andres Freund wrote:
On 2015-08-05 15:08:29 +0200, Andres Freund wrote:
We might later want to change some of the harder to maintain macros to
On Tue, Aug 11, 2015 at 10:34 PM, Noah Misch n...@leadboat.com wrote:
In my opinion this drastically increases readability and thus should be
applied. Will do so sometime tomorrow unless there's protest.
-1 to introducing more inline functions before committable code replaces what
you've
On 2015-08-12 13:00:25 -0400, Robert Haas wrote:
On Tue, Aug 11, 2015 at 10:34 PM, Noah Misch n...@leadboat.com wrote:
In my opinion this drastically increases readability and thus should be
applied. Will do so sometime tomorrow unless there's protest.
-1 to introducing more inline
On 2015-08-05 15:46:36 +0200, Andres Freund wrote:
On 2015-08-05 15:08:29 +0200, Andres Freund wrote:
We might later want to change some of the harder to maintain macros to
inline functions, but that seems better done separately.
Here's a conversion for fastgetattr() and heap_getattr().
On Tue, Aug 11, 2015 at 01:04:48PM +0200, Andres Freund wrote:
On 2015-08-05 15:46:36 +0200, Andres Freund wrote:
On 2015-08-05 15:08:29 +0200, Andres Freund wrote:
We might later want to change some of the harder to maintain macros to
inline functions, but that seems better done
On Sat, Aug 08, 2015 at 02:30:47AM +0200, Andres Freund wrote:
On 2015-08-07 20:16:20 -0400, Noah Misch wrote:
I agree that lock.h offers little to frontend code. Headers that the
lockdefs.h patch made usable in the frontend, particularly genam.h and
hash.h,
are no better.
It's not
On Fri, Aug 07, 2015 at 03:18:06PM +0200, Andres Freund wrote:
On 2015-08-06 23:23:43 -0400, Noah Misch wrote:
On Thu, Aug 06, 2015 at 05:34:50PM +0200, Andres Freund wrote:
On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
@@ -0,0 +1,56 @@
On 2015-08-07 20:16:20 -0400, Noah Misch wrote:
I agree that lock.h offers little to frontend code. Headers that the
lockdefs.h patch made usable in the frontend, particularly genam.h and hash.h,
are no better.
It's not that simple. Those two, and tuptoaster.h, are actually somewhat
validly
Andres Freund and...@anarazel.de writes:
On 2015-08-07 20:16:20 -0400, Noah Misch wrote:
On another note, I'm perplexed by the high speed commits from this thread.
Commit de6fd1c landed just 191 minutes after you posted the first version of
its patch. Now lockdefs.h is committed, right in the
On 2015-08-07 14:48:43 -0400, Tom Lane wrote:
Indeed, but the buildfarm results say that the set of such platforms is
nearly empty. It's very likely that a lot of third-party authors won't
ever care if their code doesn't build on such platforms; certainly not
nearly as much as they'll care if
On 2015-08-06 23:23:43 -0400, Noah Misch wrote:
On Thu, Aug 06, 2015 at 05:34:50PM +0200, Andres Freund wrote:
On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
@@ -0,0 +1,56 @@
+/*-
+
On 2015-08-05 21:39:26 -0400, Noah Misch wrote:
On Wed, Aug 05, 2015 at 10:32:48AM -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Wasn't the point that 32 bit AIX as a whole hasn't been supported for a
couple years now? My willingness to expend effort for that is rather
On Thu, Aug 6, 2015 at 11:34 AM, Andres Freund and...@anarazel.de wrote:
On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
I had to split of three things: LOCKMASK, the individual lock levels and
xl_standby_lock to be able to prohibit lock.h to be included by frontend
On Fri, Aug 07, 2015 at 03:20:00PM +0200, Andres Freund wrote:
Unless you have a better idea I'll now move the detection of that case
to aix.h.
Nope, that seemed right to me.
I rather liked being able to emit a warning about disabling inlines
*once* during configuration, but it's also
Andres Freund wrote:
lock.h includes lwlock.h only for the benefit of the three
LockHashPartition*
macros. Those macros are pieces of the lock.c implementation that cross
into
proc.c, not pieces of the lock.c public API.
I argued that way as well upthread. But I do think that Tom
On Fri, Aug 7, 2015 at 2:27 PM, Andres Freund and...@anarazel.de wrote:
On 2015-08-07 14:15:58 -0400, Robert Haas wrote:
On Fri, Aug 7, 2015 at 1:11 PM, Andres Freund and...@anarazel.de wrote:
On 2015-08-07 12:30:04 -0400, Robert Haas wrote:
It may not be included from any IN CORE frontend
Andres Freund and...@anarazel.de writes:
On 2015-08-07 14:32:35 -0400, Tom Lane wrote:
Eventually I think we're going to have to spend some effort on making a
clearer separation between front end safe and not front end safe
header files. Until we do that, though, adding these #error
Robert Haas robertmh...@gmail.com writes:
Well, I just work here, but it seems silly to me to reorgnize the
headers so that you can include fewer definitions where necessary, but
then not revise the existing headers to use the slimmed-down versions
where possible. Yeah, somebody might have to
On 2015-08-07 12:30:04 -0400, Robert Haas wrote:
It may not be included from any IN CORE frontend code, but that is not
the same thing as saying it's not included from any frontend code at
all. For example, EDB has code that includes namespace.h in frontend
code. That compiled before this
On 2015-08-07 14:32:35 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Well, I just work here, but it seems silly to me to reorgnize the
headers so that you can include fewer definitions where necessary, but
then not revise the existing headers to use the slimmed-down
On Fri, Aug 7, 2015 at 1:11 PM, Andres Freund and...@anarazel.de wrote:
On 2015-08-07 12:30:04 -0400, Robert Haas wrote:
It may not be included from any IN CORE frontend code, but that is not
the same thing as saying it's not included from any frontend code at
all. For example, EDB has code
On 2015-08-07 19:11:52 +0200, Andres Freund wrote:
I think the likelihood of actually breaking correct working extension
code that uses namespace.h that'd be broken if we removed lock.h from
namespace.h is an order of magnitude bigger than the possible impact on
frontend code.
Same with
On 2015-08-07 14:15:58 -0400, Robert Haas wrote:
On Fri, Aug 7, 2015 at 1:11 PM, Andres Freund and...@anarazel.de wrote:
On 2015-08-07 12:30:04 -0400, Robert Haas wrote:
It may not be included from any IN CORE frontend code, but that is not
the same thing as saying it's not included from
Andres Freund wrote:
You re-added the #ifndef FRONTEND there in a9baeb361d635 referencing a
buildfarm failure. It seems to originally have been added in
7507b193bc54 referencing buildfarm member warthog which unfortunately
doesn't exist anymore...
FWIW we make a point of not reusing
On Thu, Aug 06, 2015 at 05:34:50PM +0200, Andres Freund wrote:
On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
@@ -0,0 +1,56 @@
+/*-
+ *
+ * lockdefs.h
+ * Frontend exposed
On 2015-08-05 23:18:08 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
... I'm going to reshuffle things in that direction tomorrow. I'll
wait for other fallout first though. So far only gcc, xlc and clang (via
gcc frontend) have run...
In the department of other fallout,
Andres Freund and...@anarazel.de writes:
One approach is to avoid including lwlock.h/slot.h in frontend
code. That'll require some minor surgery and adding a couple includes,
but it doesn't look that bad.
Patch doing that attached.
This seems kinda messy. Looking at the contents of lock.h,
On Thu, Aug 6, 2015 at 3:09 AM, Andres Freund and...@anarazel.de wrote:
It really doesn't. It's just fallout from indirectly including lwlock.h
which includes an atomic variable. The include path leading to it is
In file included from
On 2015-08-06 10:29:39 -0400, Robert Haas wrote:
On Thu, Aug 6, 2015 at 3:09 AM, Andres Freund and...@anarazel.de wrote:
It really doesn't. It's just fallout from indirectly including lwlock.h
which includes an atomic variable. The include path leading to it is
In file included from
On 2015-08-06 10:27:52 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
One approach is to avoid including lwlock.h/slot.h in frontend
code. That'll require some minor surgery and adding a couple includes,
but it doesn't look that bad.
Patch doing that attached.
This
On Thu, Aug 6, 2015 at 10:31 AM, Andres Freund and...@anarazel.de wrote:
On 2015-08-06 10:29:39 -0400, Robert Haas wrote:
On Thu, Aug 6, 2015 at 3:09 AM, Andres Freund and...@anarazel.de wrote:
It really doesn't. It's just fallout from indirectly including lwlock.h
which includes an atomic
Andres Freund wrote:
On 2015-08-06 10:27:52 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
One approach is to avoid including lwlock.h/slot.h in frontend
code. That'll require some minor surgery and adding a couple includes,
but it doesn't look that bad.
Patch
On 2015-08-06 12:05:24 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
On 2015-08-06 10:27:52 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
One approach is to avoid including lwlock.h/slot.h in frontend
code. That'll require some minor surgery and adding a couple
On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
Andres Freund wrote:
I had to split of three things: LOCKMASK, the individual lock levels and
xl_standby_lock to be able to prohibit lock.h to be included by frontend
code. lockdefs.h works for me, counter proposals?
There weren't
Andres Freund wrote:
I had to split of three things: LOCKMASK, the individual lock levels and
xl_standby_lock to be able to prohibit lock.h to be included by frontend
code. lockdefs.h works for me, counter proposals?
There weren't any places that needed additional lock.h includes.
Ah, but
Andres Freund wrote:
On 2015-08-06 12:29:15 -0300, Alvaro Herrera wrote:
Ah, but that's because you cheated and didn't remove the include from
namespace.h ...
Well, it's not included from frontend code, so I didn't see the need?
Going through all the backend code and replacing lock.h by
On 2015-08-04 16:55:12 -0400, Robert Haas wrote:
On Tue, Aug 4, 2015 at 3:55 PM, Andres Freund and...@anarazel.de wrote:
On 2015-08-04 15:45:44 -0400, Tom Lane wrote:
I'm not sure that there's any great urgency about changing the instances
that exist now; the real point of this discussion
On 2015-08-05 14:05:24 +0200, Andres Freund wrote:
So unless somebody protests I'm going to prepare (and commit after
posting) a patch to rip out the bits of code that currently depend on
PG_USE_INLINE.
Here's that patch. I only removed code dependant on PG_USE_INLINE. We
might later want to
On 2015-08-05 15:08:29 +0200, Andres Freund wrote:
We might later want to change some of the harder to maintain macros to
inline functions, but that seems better done separately.
Here's a conversion for fastgetattr() and heap_getattr(). Not only is
the resulting code significantly more
Andres Freund and...@anarazel.de writes:
On 2015-08-05 14:05:24 +0200, Andres Freund wrote:
So unless somebody protests I'm going to prepare (and commit after
posting) a patch to rip out the bits of code that currently depend on
PG_USE_INLINE.
Here's that patch. I only removed code dependant
On 2015-08-05 10:08:10 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-08-05 14:05:24 +0200, Andres Freund wrote:
So unless somebody protests I'm going to prepare (and commit after
posting) a patch to rip out the bits of code that currently depend on
PG_USE_INLINE.
Andres Freund and...@anarazel.de writes:
On 2015-08-05 10:08:10 -0400, Tom Lane wrote:
Hmm. I notice that this removes Noah's hack from commit c53f73879f552a3c.
Do we care about breaking old versions of xlc, and if so, how are we going
to fix that? (I assume it should be possible to override
On 2015-08-05 10:23:31 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
How about moving that error check into into the aix template file and
erroring out there? Since this is master I think it's perfectly fine to
refuse to work with the buggy unsupported 32 bit compiler. The
Andres Freund and...@anarazel.de writes:
Wasn't the point that 32 bit AIX as a whole hasn't been supported for a
couple years now? My willingness to expend effort for that is rather
limited.
Well, there's one in the buildfarm. We don't generally turn off
buildfarm critters just because the
On 2015-08-05 10:32:48 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Wasn't the point that 32 bit AIX as a whole hasn't been supported for a
couple years now? My willingness to expend effort for that is rather
limited.
Well, there's one in the buildfarm.
Oh nice.
Andres Freund and...@anarazel.de writes:
Ok, lets' do it that way then. It seems the easiest way to test for this
is to use something like
# IBM XL C/C++ for AIX, V12.1 miscompiles, for 32-bit, some inline
# expansions of ginCompareItemPointers() long long arithmetic. To
# take advantage of
On 2015-08-05 11:12:34 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Ok, lets' do it that way then. It seems the easiest way to test for this
is to use something like
# IBM XL C/C++ for AIX, V12.1 miscompiles, for 32-bit, some inline
# expansions of
Andres Freund and...@anarazel.de writes:
I'm ok with that too, although I do like the warning at configure
time. I'd go with the template approach due to that, but I don't feel
strongly about it.
Meh. I did *not* like the way you proposed doing that: it looked far too
dependent on autoconf
On 2015-08-05 11:23:22 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
I'm ok with that too, although I do like the warning at configure
time. I'd go with the template approach due to that, but I don't feel
strongly about it.
Meh. I did *not* like the way you proposed
On 2015-08-05 17:19:05 +0200, Andres Freund wrote:
On 2015-08-05 11:12:34 -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Ok, lets' do it that way then. It seems the easiest way to test for this
is to use something like
# IBM XL C/C++ for AIX, V12.1 miscompiles, for
On Wed, Aug 05, 2015 at 10:32:48AM -0400, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
Wasn't the point that 32 bit AIX as a whole hasn't been supported for a
couple years now? My willingness to expend effort for that is rather
limited.
Well, there's one in the buildfarm. We
Andres Freund and...@anarazel.de writes:
... I'm going to reshuffle things in that direction tomorrow. I'll
wait for other fallout first though. So far only gcc, xlc and clang (via
gcc frontend) have run...
In the department of other fallout, pademelon is not happy:
cc -Ae -g +O0 -Wp,-H16384
On Tue, Aug 4, 2015 at 3:55 PM, Andres Freund and...@anarazel.de wrote:
On 2015-08-04 15:45:44 -0400, Tom Lane wrote:
I'm not sure that there's any great urgency about changing the instances
that exist now; the real point of this discussion is that we will allow
new code to use static inlines
Andres Freund and...@anarazel.de writes:
On 2015-08-04 15:20:14 -0400, Robert Haas wrote:
OK, so do we want to rip out all instances of the static inline dance
in favor of more straightforward coding? Do we then shut pandemelon
and any other affected buildfarm members down as unsupported, or
On 2015-08-04 15:20:14 -0400, Robert Haas wrote:
OK, so do we want to rip out all instances of the static inline dance
in favor of more straightforward coding? Do we then shut pandemelon
and any other affected buildfarm members down as unsupported, or what?
I think all that happens is that
On 2015-08-04 15:45:44 -0400, Tom Lane wrote:
I'm not sure that there's any great urgency about changing the instances
that exist now; the real point of this discussion is that we will allow
new code to use static inlines in headers.
I agree that we don't have to (and probably shouldn't) make
On Thu, Jul 2, 2015 at 12:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So far this thread is all about the costs of desupporting compilers
that don't have these features, and you're making a good argument
(that I think we all agree with) that the cost is
On Wed, Jul 1, 2015 at 6:24 PM, Andres Freund and...@anarazel.de wrote:
On 2015-07-02 00:15:14 +0200, Andres Freund wrote:
animal OS compiler inline quiet inline
varargs
brolga cygwin gcc-4.3 yy
4.3 obviously
On 2015-07-02 11:46:25 -0400, Robert Haas wrote:
In the case of static inline, the main problem with the status quo
AFAICS is that you have to do a little dance any time you'd otherwise
use a static inline function (for those following along at home, git
grep INCLUDE_DEFINITIONS src/include to
Robert Haas robertmh...@gmail.com writes:
So far this thread is all about the costs of desupporting compilers
that don't have these features, and you're making a good argument
(that I think we all agree with) that the cost is small. But you
haven't really said what the benefits are.
I made
Hi,
During the 9.5 cycle, and earlier, the topic of increasing our minimum
bar for compilers came up a bunch of times. Specifically whether we
still should continue to use C90 as a baseline.
I think the time has come to rely at least on some newer features.
At the very least I think we should
On Wed, Jul 1, 2015 at 9:14 AM, Andres Freund and...@anarazel.de wrote:
At the very least I think we should start to rely on 'static inline's
working. There is not, and hasn't been for a while, any buildfarm animal
that does not support it and we go through some ugly lengths to avoid
relying
Andres Freund and...@anarazel.de writes:
At the very least I think we should start to rely on 'static inline's
working. There is not, and hasn't been for a while, any buildfarm animal
that does not support it
pademelon doesn't.
Also, I think there are some other non-gcc animals that nominally
1 - 100 of 109 matches
Mail list logo
