On 2015-03-22 22:28:01 +0100, Andreas Karlsson wrote:
> On 03/22/2015 10:20 PM, Andres Freund wrote:
> >Yes, or a compiler bug. I looked through the code again and found and
> >fixed one minor bug, but that doesnt' explain the problem.
>
> Strangely enough the bug looks like it has been fixed at j
On 2015-03-22 22:20:49 +0100, Andres Freund wrote:
> A compiler bug looks like a not unreasonable bet at this point. I've
> asked Andrew to recompile without optimizations... We'll see whether
> that makes a difference. Jacana is the only compiler with gcc 4.8.1 (or
> is it 4.8.0? there's conflicti
On 03/22/2015 10:20 PM, Andres Freund wrote:
Yes, or a compiler bug. I looked through the code again and found and
fixed one minor bug, but that doesnt' explain the problem.
Strangely enough the bug looks like it has been fixed at jacana after
your fix of my copypasto. Maybe the bug is random,
On 2015-03-22 22:00:13 +0100, Petr Jelinek wrote:
> On 22/03/15 13:59, Andreas Karlsson wrote:
> >Would this mean the bug is most likely somewhere in
> >int128_to_numericvar()? Maybe that version of gcc has a bug in some
> >__int128 operator or I messed up the code there somehow.
Yes, or a compile
On 22/03/15 13:59, Andreas Karlsson wrote:
On 03/22/2015 11:47 AM, Petr Jelinek wrote:
On 22/03/15 10:35, Andres Freund wrote:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2015-03-21%2003%3A01%3A21
That's the stuff looking like random memory that I talk about above...
On 03/22/2015 11:47 AM, Petr Jelinek wrote:
On 22/03/15 10:35, Andres Freund wrote:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2015-03-21%2003%3A01%3A21
That's the stuff looking like random memory that I talk about above...
If you look at it closely, it's actually not
On 22/03/15 10:35, Andres Freund wrote:
On March 22, 2015 10:34:04 AM GMT+01:00, Michael Paquier
wrote:
On Sun, Mar 22, 2015 at 6:22 PM, Andres Freund
That's due to a different patch though, right? When I checked earlier
only jacana had problems due to this, and it looked like random memory
On Sun, Mar 22, 2015 at 6:34 PM, David Rowley wrote:
> On 22 March 2015 at 22:22, Andres Freund wrote:
>>
>> On March 22, 2015 6:17:28 AM GMT+01:00, Michael Paquier
>> wrote:
>> >On Sun, Mar 22, 2015 at 12:32 AM, Tom Lane wrote:
>> >> Andres Freund writes:
>> >>> Pushed with that additional ch
On March 22, 2015 10:34:04 AM GMT+01:00, Michael Paquier
wrote:
>On Sun, Mar 22, 2015 at 6:22 PM, Andres Freund
>wrote:
>> On March 22, 2015 6:17:28 AM GMT+01:00, Michael Paquier
> wrote:
>>>On Sun, Mar 22, 2015 at 12:32 AM, Tom Lane wrote:
Andres Freund writes:
> Pushed with that add
On 22 March 2015 at 22:22, Andres Freund wrote:
> On March 22, 2015 6:17:28 AM GMT+01:00, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
> >On Sun, Mar 22, 2015 at 12:32 AM, Tom Lane wrote:
> >> Andres Freund writes:
> >>> Pushed with that additional change. Let's see if the buildfarm
>
On Sun, Mar 22, 2015 at 6:22 PM, Andres Freund wrote:
> On March 22, 2015 6:17:28 AM GMT+01:00, Michael Paquier
> wrote:
>>On Sun, Mar 22, 2015 at 12:32 AM, Tom Lane wrote:
>>> Andres Freund writes:
Pushed with that additional change. Let's see if the buildfarm
>>thinks.
>>>
>>> jacana, a
On March 22, 2015 6:17:28 AM GMT+01:00, Michael Paquier
wrote:
>On Sun, Mar 22, 2015 at 12:32 AM, Tom Lane wrote:
>> Andres Freund writes:
>>> Pushed with that additional change. Let's see if the buildfarm
>thinks.
>>
>> jacana, apparently alone among buildfarm members, does not like it.
>
>All
On 22 March 2015 at 18:17, Michael Paquier
wrote:
> On Sun, Mar 22, 2015 at 12:32 AM, Tom Lane wrote:
> > Andres Freund writes:
> >> Pushed with that additional change. Let's see if the buildfarm thinks.
> >
> > jacana, apparently alone among buildfarm members, does not like it.
>
> All the win
On Sun, Mar 22, 2015 at 2:17 PM, Michael Paquier
wrote:
> On Sun, Mar 22, 2015 at 12:32 AM, Tom Lane wrote:
>> Andres Freund writes:
>>> Pushed with that additional change. Let's see if the buildfarm thinks.
>>
>> jacana, apparently alone among buildfarm members, does not like it.
>
> All the wi
On Sun, Mar 22, 2015 at 12:32 AM, Tom Lane wrote:
> Andres Freund writes:
>> Pushed with that additional change. Let's see if the buildfarm thinks.
>
> jacana, apparently alone among buildfarm members, does not like it.
All the windows nodes don't pass tests with this patch, the difference
is in
Andres Freund writes:
> Pushed with that additional change. Let's see if the buildfarm thinks.
jacana, apparently alone among buildfarm members, does not like it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Fri, Mar 20, 2015 at 2:39 AM, Andreas Karlsson wrote:
> On 03/20/2015 10:32 AM, Andres Freund wrote:
>>
>> Pushed with that additional change. Let's see if the buildfarm thinks.
>>
>> Thanks for the feature.
>
> Thanks to you and all the reviewers for helping me out with it.
Indeed. Thanks fo
On 03/20/2015 10:32 AM, Andres Freund wrote:
Pushed with that additional change. Let's see if the buildfarm thinks.
Thanks for the feature.
Thanks to you and all the reviewers for helping me out with it.
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On 2015-03-20 00:49:07 +0100, Andreas Karlsson wrote:
> On 03/19/2015 07:08 PM, Andres Freund wrote:
> >Working on committing this:
>
> Nice fixes. Sorry about forgetting numericvar_to_int*.
>
> As for the reviewers those lists look pretty much correct. David Rowley
> should probably be added to
On Thu, Mar 19, 2015 at 4:49 PM, Andreas Karlsson wrote:
> Nice fixes. Sorry about forgetting numericvar_to_int*.
>
> As for the reviewers those lists look pretty much correct. David Rowley
> should probably be added to the second patch for his early review and
> benchmarking.
This also seems fin
On 03/19/2015 07:08 PM, Andres Freund wrote:
Working on committing this:
Nice fixes. Sorry about forgetting numericvar_to_int*.
As for the reviewers those lists look pretty much correct. David Rowley
should probably be added to the second patch for his early review and
benchmarking.
--
And
Hi,
Working on committing this:
* Converted the configure test to AC_LINK_IFELSE
* I dislike the way the configure test and the resulting HAVE_* is
named. This imo shouldn't be so gcc specific, even if it right now
only detects gcc support. Changed.
* Furthermore does the test use 64bit lite
On 03/18/2015 11:59 PM, Peter Geoghegan wrote:
Okay. Attached revision has a few tweaks that reflect the status of
int128/uint128 as specialized types that are basically only useful for
this optimization, or other similar optimizations on compilers that
either are GCC, or aim to be compatible wit
On Wed, Mar 18, 2015 at 4:07 PM, Andres Freund wrote:
> Given that we don't rely on C99, I don't think that actually
> matters. Lots of our platforms build on pre C99 compilers... I think it
> makes sense to say that this currently only tests for a gcc extension
> and might be extended in the futu
On 2015-03-18 15:59:52 -0700, Peter Geoghegan wrote:
> Okay. Attached revision has a few tweaks that reflect the status of
> int128/uint128 as specialized types that are basically only useful for
> this optimization, or other similar optimizations on compilers that
> either are GCC, or aim to be co
On Wed, Mar 18, 2015 at 3:16 PM, Andres Freund wrote:
>> For another, Andreas has chosen to lump together __int128 and unsigned
>> __int128 into one test, where the latter really doesn't receive
>> coverage.
>
> On my urging actually. It's pretty darn unlikely that only one variant
> will work.
I
On 2015-03-18 14:00:51 -0700, Peter Geoghegan wrote:
> Anyway, I think that it's not quite the same. For one thing, we're
> talking about a GCC extension, not a type described by C99. We don't
> care about snprintf support, for example.
I don't see that that has any consequence wrt Andreas' test.
On Wed, Mar 18, 2015 at 1:05 AM, Andres Freund wrote:
> I think it's a pretty direct copy of the 64bit code. I'm not entirely
> sure why this needs a AC_TRY_RUN with a compile fallback (for cross) and
> why a AC_TRY_LINK isn't sufficient? But then, you just copied that
> decision.
Good point.
An
On 2015-03-17 20:50:48 -0700, Peter Geoghegan wrote:
> On Mon, Mar 16, 2015 at 6:22 AM, Petr Jelinek wrote:
> >> Do you think it is ready for committer?
> >>
> >
> > In my opinion, yes.
>
> If it wasn't for the autoconf parts of this, I'd probably agree with
> you. I need to go over that more care
On Mon, Mar 16, 2015 at 6:22 AM, Petr Jelinek wrote:
>> Do you think it is ready for committer?
>>
>
> In my opinion, yes.
If it wasn't for the autoconf parts of this, I'd probably agree with
you. I need to go over that more carefully.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing li
On 16/03/15 00:37, Andreas Karlsson wrote:
On 03/15/2015 09:47 PM, Petr Jelinek wrote:
It's almost the same thing as you wrote but the 128 bit and 64 bit
optimizations are put on the same "level" of optimized routines.
But this is nitpicking at this point, I am happy with the patch as it
stands
On 03/15/2015 09:47 PM, Petr Jelinek wrote:
It's almost the same thing as you wrote but the 128 bit and 64 bit
optimizations are put on the same "level" of optimized routines.
But this is nitpicking at this point, I am happy with the patch as it
stands right now.
Do you think it is ready for c
On 14/03/15 04:17, Andreas Karlsson wrote:
On 03/13/2015 10:22 PM, Peter Geoghegan wrote:
On Thu, Mar 12, 2015 at 6:23 PM, Andreas Karlsson
wrote:
/*
* Integer data types use Numeric accumulators to share code and
avoid risk
* of overflow. To speed up aggregation 128-bit integer
accumulat
On 03/13/2015 10:22 PM, Peter Geoghegan wrote:
On Thu, Mar 12, 2015 at 6:23 PM, Andreas Karlsson wrote:
/*
* Integer data types use Numeric accumulators to share code and avoid risk
* of overflow. To speed up aggregation 128-bit integer accumulators are
* used instead where sum(X) or sum
On Thu, Mar 12, 2015 at 6:23 PM, Andreas Karlsson wrote:
> Fixed.
Did you intend to attach a patch here?
>> I think you should talk about the new thing first (just after the
>> extant, first sentence "Integer data types use Numeric..."). Refer to
>> where 128-bit integers are used and how, and o
On 03/10/2015 02:26 AM, Peter Geoghegan wrote:
On Mon, Mar 9, 2015 at 5:37 PM, Andreas Karlsson wrote:
int128-agg-v7.patch
I see a spelling error:
"+ * On platforms which support 128-bit integers some aggergates instead use a"
Fixed.
I think you should talk about the new thing first (jus
On Mon, Mar 9, 2015 at 5:37 PM, Andreas Karlsson wrote:
> int128-agg-v7.patch
I see a spelling error:
"+ * On platforms which support 128-bit integers some aggergates instead use a"
Other than that, the patch looks pretty good to me. You're
generalizing from the example of existing routines for
On 03/07/2015 07:18 PM, Petr Jelinek wrote:
What I am wondering is if those numeric_int16_* functions that also deal
with either the Int128AggState or NumericAggState should be renamed in
similar fashion.
Here is a patch where I have renamed the functions.
int128-agg-v7.patch
- Rename numeric
On 09/03/15 18:39, David Fetter wrote:
On Mon, Mar 09, 2015 at 01:39:04PM +0100, Andreas Karlsson wrote:
On 03/07/2015 07:18 PM, Petr Jelinek wrote:
What I am wondering is if those numeric_int16_* functions that also deal
with either the Int128AggState or NumericAggState should be renamed in
s
On Mon, Mar 09, 2015 at 01:39:04PM +0100, Andreas Karlsson wrote:
> On 03/07/2015 07:18 PM, Petr Jelinek wrote:
>
> >What I am wondering is if those numeric_int16_* functions that also deal
> >with either the Int128AggState or NumericAggState should be renamed in
> >similar fashion.
>
> You mean
On 09/03/15 13:39, Andreas Karlsson wrote:
On 03/07/2015 07:18 PM, Petr Jelinek wrote:
What I am wondering is if those numeric_int16_* functions that also deal
with either the Int128AggState or NumericAggState should be renamed in
similar fashion.
You mean something like numeric_poly_sum inst
On 03/07/2015 07:18 PM, Petr Jelinek wrote:
What I am wondering is if those numeric_int16_* functions that also deal
with either the Int128AggState or NumericAggState should be renamed in
similar fashion.
You mean something like numeric_poly_sum instead of numeric_int16_sum? I
personally am n
On 04/03/15 23:51, Andreas Karlsson wrote:
On 01/29/2015 12:28 AM, Peter Geoghegan wrote:
* I'm not sure about the idea of "polymorphic" catalog functions (that
return the type "internal", but the actual struct returned varying
based on build settings).
I tend to think that things would be bett
On 01/29/2015 12:28 AM, Peter Geoghegan wrote:
On Mon, Jan 26, 2015 at 11:21 PM, Andreas Karlsson wrote:
Do you also think the SQL functions should be named numeric_int128_sum,
numeric_int128_avg, etc?
Some quick review comments. These apply to int128-agg-v5.patch.
* Why is there no declarat
On 02/13/2015 02:07 PM, Michael Paquier wrote:
Andreas, are you planning to continue working on this patch? Peter has
provided some comments that are still unanswered.
Yes, but I am quite busy right now. I will try to find time some time
later this week.
--
Andreas Karlsson
--
Sent via pgs
On Thu, Jan 29, 2015 at 8:28 AM, Peter Geoghegan wrote:
> On Mon, Jan 26, 2015 at 11:21 PM, Andreas Karlsson
> wrote:
> > Do you also think the SQL functions should be named numeric_int128_sum,
> > numeric_int128_avg, etc?
>
> Some quick review comments. These apply to int128-agg-v5.patch.
>
An
On Mon, Jan 26, 2015 at 11:21 PM, Andreas Karlsson wrote:
> Do you also think the SQL functions should be named numeric_int128_sum,
> numeric_int128_avg, etc?
Some quick review comments. These apply to int128-agg-v5.patch.
* Why is there no declaration of the function
numeric_int16_stddev_intern
On 01/27/2015 09:05 AM, Andres Freund wrote:
On 2015-01-27 08:21:57 +0100, Andreas Karlsson wrote:
On 01/23/2015 02:58 AM, Petr Jelinek wrote:
On 23/01/15 00:40, Andreas Karlsson wrote:
- Renamed some things from int12 to int128, there are still some places
with int16 which I am not sure what
On 2015-01-27 08:21:57 +0100, Andreas Karlsson wrote:
> On 01/23/2015 02:58 AM, Petr Jelinek wrote:
> >On 23/01/15 00:40, Andreas Karlsson wrote:
> >>- Renamed some things from int12 to int128, there are still some places
> >>with int16 which I am not sure what to do with.
> >
> >I'd vote for renam
On 01/23/2015 02:58 AM, Petr Jelinek wrote:
On 23/01/15 00:40, Andreas Karlsson wrote:
- Renamed some things from int12 to int128, there are still some places
with int16 which I am not sure what to do with.
I'd vote for renaming them to int128 too, there is enough C functions
that user int16 f
On 23/01/15 00:40, Andreas Karlsson wrote:
- Renamed some things from int12 to int128, there are still some places
with int16 which I am not sure what to do with.
I'd vote for renaming them to int128 too, there is enough C functions
that user int16 for 16bit integer that this is going to be
A new version of the patch is attached, which changes the following:
- Changed from using __int128_t to __int128.
- Actually compiles and runs code in configure to see that int128 works.
- No longer tests for __uint128_t.
- Updated pg_config.h.win32
- Renamed some things from int12 to int128, the
On 01/11/2015 02:36 AM, Andres Freund wrote:
a) Afaics only __int128/unsigned __int128 is defined. See
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
b) I'm doubtful that AC_CHECK_TYPES is a sufficiently good test on all
platforms. IIRC gcc will generate calls to functions to d
On 12/31/2014 03:00 PM, David Rowley wrote:
hmm, I think it should be changed to int128 then. Pitty int4 was
selected as a name instead of int32 back in the day...
I'm going to mark the patch as waiting on author, pending those two changes.
My view with the size estimates change is that if a c
On 2015-01-11 05:07:13 +0100, Andreas Karlsson wrote:
> On 01/11/2015 02:36 AM, Andres Freund wrote:
> >a) Afaics only __int128/unsigned __int128 is defined. See
> >https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
>
> Both GCC and Clang defines both of them. Which you use seems to just
On 11/01/15 05:07, Andreas Karlsson wrote:
On 01/11/2015 02:36 AM, Andres Freund wrote:
@@ -3030,6 +3139,18 @@ int8_avg_accum(PG_FUNCTION_ARGS)
Datum
int2_accum_inv(PG_FUNCTION_ARGS)
{
+#ifdef HAVE_INT128
+Int16AggState *state;
+
+state = PG_ARGISNULL(0) ? NULL : (Int16AggState *)
Andreas Karlsson writes:
> On 01/11/2015 02:36 AM, Andres Freund wrote:
>> b) I'm doubtful that AC_CHECK_TYPES is a sufficiently good test on all
>> platforms.
> Should I fix it to actually compile some code which uses the 128-bit types?
We used to have code in configure to test that int64 works
On 01/11/2015 02:36 AM, Andres Freund wrote:
a) Afaics only __int128/unsigned __int128 is defined. See
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
Both GCC and Clang defines both of them. Which you use seems to just be
a matter of preference.
b) I'm doubtful that AC_CHECK_T
Hi,
> +# Check if platform support gcc style 128-bit integers.
> +AC_CHECK_TYPES([__int128_t, __uint128_t], [], [], [])
Hm, I'm not sure that's sufficent. Three things:
a) Afaics only __int128/unsigned __int128 is defined. See
https://gcc.gnu.org/onlinedocs/gcc/_005f_005fint128.html
b) I'm d
On Fri, Jan 2, 2015 at 7:57 PM, Jim Nasby wrote:
> On 1/2/15, 4:18 PM, Tom Lane wrote:
>>
>> Heikki Linnakangas writes:
>>>
>>> >On 01/02/2015 11:41 PM, Tom Lane wrote:
>>What might be worth trying is establishing a hard-and-fast boundary
>>between C land and SQL land, with bitwise
On 1/2/15, 4:18 PM, Tom Lane wrote:
Heikki Linnakangas writes:
>On 01/02/2015 11:41 PM, Tom Lane wrote:
>>What might be worth trying is establishing a hard-and-fast boundary
>>between C land and SQL land, with bitwise names in C and bytewise names
>>in SQL. This would mean, for example, that
Heikki Linnakangas writes:
> On 01/02/2015 11:41 PM, Tom Lane wrote:
>> What might be worth trying is establishing a hard-and-fast boundary
>> between C land and SQL land, with bitwise names in C and bytewise names
>> in SQL. This would mean, for example, that int4pl() would be renamed to
>> int3
On 01/02/2015 11:41 PM, Tom Lane wrote:
What might be worth trying is establishing a hard-and-fast boundary
between C land and SQL land, with bitwise names in C and bytewise names
in SQL. This would mean, for example, that int4pl() would be renamed to
int32pl() so far as the C function goes, but
Jim Nasby writes:
> On 12/31/14, 8:13 AM, Andres Freund wrote:
>> Note that the C datatype has been int32/int64 for a while now, it's just
>> the SQL datatype and the names of its support functions. Given that,
>> afaiu, we're talking about the C datatype it seems pretty clear that it
>> should be
On 12/31/14, 8:13 AM, Andres Freund wrote:
On 2015-01-01 03:00:50 +1300, David Rowley wrote:
2. References to int16 meaning 16 bytes. I'm really in two minds about
this,
it's quite nice to keep the natural flow, int4, int8, int16, but I can't
help think that this will confuse someone one day.
On Wed, Dec 31, 2014 at 9:00 AM, David Rowley wrote:
> Yeah, that's what I was talking about.
> I'm just looking at the code which uses this size estimate in
> choose_hashed_grouping(). I'd be a bit worried giving the difference between
> 48 and 128 that we'd under estimate the hash size too much
On 2015-01-01 03:00:50 +1300, David Rowley wrote:
> > > 2. References to int16 meaning 16 bytes. I'm really in two minds about
> > this,
> > > it's quite nice to keep the natural flow, int4, int8, int16, but I can't
> > > help think that this will confuse someone one day. I think it'll be a
> > lon
On 31 December 2014 at 18:20, Robert Haas wrote:
> On Fri, Dec 26, 2014 at 7:57 AM, David Rowley
> wrote:
> > 1. Do we need to keep the 128 byte aggregate state size for machines
> without
> > 128 bit ints? This has been reduced to 48 bytes in the patch, which is in
> > favour code being compile
On Fri, Dec 26, 2014 at 7:57 AM, David Rowley wrote:
> 1. Do we need to keep the 128 byte aggregate state size for machines without
> 128 bit ints? This has been reduced to 48 bytes in the patch, which is in
> favour code being compiled with a compiler which has 128 bit ints. I kind
> of think th
On 24 December 2014 at 16:04, Andreas Karlsson wrote:
On 12/16/2014 11:04 AM, David Rowley wrote:> These are some very promising
> performance increases.
>
>>
>> I've done a quick pass of reading the patch. I currently don't have a
>> system with a 128bit int type, but I'm working on that.
>>
>
>
On 12/16/2014 11:04 AM, David Rowley wrote:> These are some very
promising performance increases.
I've done a quick pass of reading the patch. I currently don't have a
system with a 128bit int type, but I'm working on that.
Sorry for taking some time to get back. I have been busy before
Chris
On 12/22/2014 11:47 PM, Oskari Saarenmaa wrote:
__int128_t and __uint128_t are GCC extensions and are not related to
stdint.h.
>> [...]
>
These changes don't match what my autoconf does. Not a big deal I guess,
but if this is merged as-is the next time someone runs autoreconf it'll
write thes
On Fri, Nov 14, 2014 at 01:57:16AM +0100, Andreas Karlsson wrote:
> *** a/configure.in
> --- b/configure.in
> *** AC_DEFINE_UNQUOTED(MAXIMUM_ALIGNOF, $MAX
> *** 1751,1756
> --- 1751,1759
> AC_CHECK_TYPES([int8, uint8, int64, uint64], [], [],
> [#include ])
>
> + # Check
On Tue, Dec 16, 2014 at 7:04 PM, David Rowley wrote:
> It also looks like your OIDs have been nabbed by some jsonb stuff.
> DETAIL: Key (oid)=(3267) is duplicated.
Use src/include/catalog/unused_oids to track the OIDs not yet used in
the catalogs when adding new objects for a feature.
--
Michael
On 14 November 2014 at 13:57, Andreas Karlsson wrote:
>
> On 11/13/2014 03:38 AM, Alvaro Herrera wrote:
>
>> configure is a generated file. If your patch touches it but not
>> configure.in, there is a problem.
>>
>
> Thanks for pointing it out, I have now fixed it.
>
>
>
Hi Andreas,
These are so
On 11/14/2014 02:25 AM, Peter Eisentraut wrote:
There is something odd about your patch. I claims that all files are
new files, e.g.:
diff --git a/src/backend/utils/adt/numeric.c
b/src/backend/utils/adt/numeric.c
new file mode 100644
index d61af92..98183b4
*** a/src/backend/utils/adt/numeric.c
On 11/13/14 7:57 PM, Andreas Karlsson wrote:
> On 11/13/2014 03:38 AM, Alvaro Herrera wrote:
>> configure is a generated file. If your patch touches it but not
>> configure.in, there is a problem.
>
> Thanks for pointing it out, I have now fixed it.
There is something odd about your patch. I cl
On 11/13/2014 03:38 AM, Alvaro Herrera wrote:
configure is a generated file. If your patch touches it but not
configure.in, there is a problem.
Thanks for pointing it out, I have now fixed it.
--
Andreas Karlsson
diff --git a/configure b/configure
new file mode 100755
index c4f70e8..bb801b4
*
Andreas Karlsson wrote:
> On 11/13/2014 02:03 AM, Andreas Karlsson wrote:
> >Here is version 2 of the patch which detects the presence of gcc/clang
> >style 128-bit integers and has been cleaned up to a reviewable state. I
> >have not added support for any other compilers since I found no
> >docume
On 11/13/2014 02:03 AM, Andreas Karlsson wrote:
Here is version 2 of the patch which detects the presence of gcc/clang
style 128-bit integers and has been cleaned up to a reviewable state. I
have not added support for any other compilers since I found no
documentation 128-bit support with icc or
Hi,
Here is version 2 of the patch which detects the presence of gcc/clang
style 128-bit integers and has been cleaned up to a reviewable state. I
have not added support for any other compilers since I found no
documentation 128-bit support with icc or MSVC. I do not have access to
any Window
81 matches
Mail list logo
