On 12/14/2011 04:43 AM, Mark Cave-Ayland wrote:
On 12/12/11 15:00, Andrew Dunstan wrote:
Yeah, fair enough. I'll work on that.
If we're talking about adding support for a previously-unsupported
Definitely do this (and then file a bug report with the project). I've
worked with both Kai and
On 14/12/11 13:59, Andrew Dunstan wrote:
Hmm. Yeah, if I remove -O0 and instead set CFLAGS to -ffloat-store the
error goes away.
So, would we want to use that just for this file, or for the whole build?
Well the latest documentation for gcc gives 2 options: -ffloat-store and
Andrew Dunstan and...@dunslane.net writes:
Done and done (see
https://sourceforge.net/tracker/?func=detailaid=3458244group_id=202880atid=983354).
Did you see Kai's update on the ticket? If this is the case, I know
that we have seen similar bugs with PostGIS and the work-around has
been
On Wed, Dec 14, 2011 at 11:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
-ffloat-store is a brute force solution, I think, and would affect old
versions of gcc that don't exhibit any problems. I would suggest
altering configure to see whether the compiler recognizes
-fexcess-precision=standard
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 14, 2011 at 11:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
-ffloat-store is a brute force solution, I think, and would affect old
versions of gcc that don't exhibit any problems. I would suggest
altering configure to see whether the compiler
On Wed, Dec 14, 2011 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
AFAICS it's really impractical to do that. The code Andrew is having
problems with is essentially
double a,b,c;
...
a = b * c;
if (isinf(a)) throw error;
and the problem is that the
Robert Haas robertmh...@gmail.com writes:
Uh, wow. That really is pretty insane. How is anyone supposed to
write sensible code around that non-API?
Usability seems to be very low on the gcc project's list of goals
these days.
Personally I think this sort of thing might be fine if it were
On 12/14/2011 11:14 AM, Tom Lane wrote:
-ffloat-store is a brute force solution, I think, and would affect old
versions of gcc that don't exhibit any problems. I would suggest
altering configure to see whether the compiler recognizes
-fexcess-precision=standard and adding that to CFLAGS if
Andrew Dunstan and...@dunslane.net writes:
+ # Disable FP optimizations that cause isinf errors on gcc 4.5+
+ PGAC_PROG_CC_CFLAGS_OPT([-fexcess-precision=standard])
Looks sane to me, except isinf errors is an awfully narrow reading of
the problem. Maybe just say assorted errors?
On 12/14/2011 03:09 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
+ # Disable FP optimizations that cause isinf errors on gcc 4.5+
+ PGAC_PROG_CC_CFLAGS_OPT([-fexcess-precision=standard])
Looks sane to me, except isinf errors is an awfully narrow reading of
the
On -10/01/37 20:59, Andrew Dunstan wrote:
This is apparently an optimization bug in the compiler. If I turn
optimization off (CFLAGS=-O0) it goes away. Ick.
So at the moment I'm a bit blocked. I can't really file a bug because
the
compiler can't currently be used to build postgres, I don't
Am Freitag, 9. Dezember 2011, 15:31:17 schrieb Andrew Dunstan:
Yeah, fair enough. I'll work on that.
Many thanks for reviewing, tweaking and commiting the patch!
One thing I wonder about, is this snippet. Is the define really needed now?
* The Mingw64 headers choke if this is already defined -
On 12/12/2011 06:43 AM, Mark Cave-Ayland wrote:
configuration, it seems to me that it would be fine to commit a patch
that made everything work, but for the compiler bug. We could refrain
from stating that we officially support that configuration until the
compiler bug is fixed, or even
On 12/12/2011 09:54 AM, Lars Kanis wrote:
Am Freitag, 9. Dezember 2011, 15:31:17 schrieb Andrew Dunstan:
Yeah, fair enough. I'll work on that.
Many thanks for reviewing, tweaking and commiting the patch!
One thing I wonder about, is this snippet. Is the define really needed now?
* The
Am Montag, 12. Dezember 2011, 10:19:46 schrieb Andrew Dunstan:
On 12/12/2011 09:54 AM, Lars Kanis wrote:
Am Freitag, 9. Dezember 2011, 15:31:17 schrieb Andrew Dunstan:
Yeah, fair enough. I'll work on that.
Many thanks for reviewing, tweaking and commiting the patch!
One thing I wonder
On Thu, Dec 8, 2011 at 12:46 PM, Andrew Dunstan and...@dunslane.net wrote:
This is apparently an optimization bug in the compiler. If I turn
optimization off (CFLAGS=-O0) it goes away. Ick.
So at the moment I'm a bit blocked. I can't really file a bug because the
compiler can't currently be
On 12/09/2011 03:11 PM, Robert Haas wrote:
On Thu, Dec 8, 2011 at 12:46 PM, Andrew Dunstanand...@dunslane.net wrote:
This is apparently an optimization bug in the compiler. If I turn
optimization off (CFLAGS=-O0) it goes away. Ick.
So at the moment I'm a bit blocked. I can't really file a
On 12/05/2011 06:27 PM, Andrew Dunstan wrote:
$ cat regression.diffs
***
C:/MinGW/msys/1.0/home/pgrunner/bf/root32/HEAD/pgsql/src/test/regress/expected/float8-exp-three-digits-win32.out
Fri Nov 25 14:24:49 2011
---
Hi,
FYI I've been testing with the attached patch.
We'll need to construct a configure test for HAVE_CRTDEFS_H.
Isn't it enough to add the name in configure.in and run autoconf to
update configure and autoheaders to update pg_config.h.in?
The check of win32 before large file perhaps should
Hi,
If we are not to use 64 bit file size (and time),
#undef stat may be sufficient. The #undef should be
before the prototype of pgwin32_safestat because the
#define stat _stat64 affect both the function and struct stat.
The #undef stat necessitate #undef fstat as the parameter
struct stat * is
On 12/05/2011 09:31 AM, NISHIYAMA Tomoaki wrote:
Hi,
If we are not to use 64 bit file size (and time),
#undef stat may be sufficient. The #undef should be
before the prototype of pgwin32_safestat because the
#define stat _stat64 affect both the function and struct stat.
The #undef stat
Hi,
I found error on #define stat _stat64 occurs on Mingw-w64 (x86_64-w64-mingw32)
gcc version 4.7.0 20111203 (experimental) (GCC)
The code can be compiled with
diff --git a/src/include/port.h b/src/include/port.h
index eceb4bf..78d5c92 100644
--- a/src/include/port.h
+++ b/src/include/port.h
On Sun, Dec 4, 2011 at 09:14, NISHIYAMA Tomoaki
tomoa...@staff.kanazawa-u.ac.jp wrote:
Hi,
I found error on #define stat _stat64 occurs on Mingw-w64 (x86_64-w64-mingw32)
gcc version 4.7.0 20111203 (experimental) (GCC)
The code can be compiled with
diff --git a/src/include/port.h
On 12/04/2011 06:31 AM, Magnus Hagander wrote:
On Sun, Dec 4, 2011 at 09:14, NISHIYAMA Tomoaki
tomoa...@staff.kanazawa-u.ac.jp wrote:
Hi,
I found error on #define stat _stat64 occurs on Mingw-w64 (x86_64-w64-mingw32)
gcc version 4.7.0 20111203 (experimental) (GCC)
The code can be compiled
Hi,
A new patch:
check for the presence of crtdefs.h in configure
-#if _MSC_VER = 1400 || defined(WIN64)
+#if _MSC_VER = 1400 || HAVE_CRTDEFS_H
#define errcode __msvc_errcode
#include crtdefs.h
#undef errcode
Perhaps there is no guarantee that mingw (not -w64) may not have crtdefs.h in
the
On Sat, Dec 3, 2011 at 09:24, NISHIYAMA Tomoaki
tomoa...@staff.kanazawa-u.ac.jp wrote:
Hi,
A new patch:
check for the presence of crtdefs.h in configure
-#if _MSC_VER = 1400 || defined(WIN64)
+#if _MSC_VER = 1400 || HAVE_CRTDEFS_H
#define errcode __msvc_errcode
#include crtdefs.h
Hi,
Have you verified if tihs affects _MSC_VER 1400? Suddently that
branch would care about HAVE_CRTDEFS_H, and I'm not sure if that's
something we need to worry about.
I have no MSVC. In that sense it is not verified in fact, and I hope
those who knows well would kindly comment on it.
On Sat, Dec 3, 2011 at 15:49, NISHIYAMA Tomoaki
tomoa...@staff.kanazawa-u.ac.jp wrote:
Hi,
Have you verified if tihs affects _MSC_VER 1400? Suddently that
branch would care about HAVE_CRTDEFS_H, and I'm not sure if that's
something we need to worry about.
I have no MSVC. In that sense it
On 12/03/2011 09:59 AM, Magnus Hagander wrote:
On Sat, Dec 3, 2011 at 15:49, NISHIYAMA Tomoaki
tomoa...@staff.kanazawa-u.ac.jp wrote:
Hi,
Have you verified if tihs affects _MSC_VER 1400? Suddently that
branch would care about HAVE_CRTDEFS_H, and I'm not sure if that's
something we need to
On 12/03/2011 06:12 PM, Andrew Dunstan wrote:
On 12/03/2011 09:59 AM, Magnus Hagander wrote:
On Sat, Dec 3, 2011 at 15:49, NISHIYAMA Tomoaki
tomoa...@staff.kanazawa-u.ac.jp wrote:
Hi,
Have you verified if tihs affects _MSC_VER 1400? Suddently that
branch would care about
Hi,
On 2011/12/04, at 9:45, Andrew Dunstan wrote:
Yes, but there's a deal more work to do here. This whole thing is falling
over in my build environment (64 bit Windows 7, MinGW/MSys, the machine that
runs pitta on the buildfarm.)
This is a long way from a done deal.
In particular,
On 11/27/2011 09:18 AM, NISHIYAMA Tomoaki wrote:
Hi,
+/* __MINGW64_VERSION_MAJOR is related to both 32/64 bit gcc compiles by
+ * mingw-w64, however it gots defined only after
Why not use __MINGW32__, which is defined without including any headers?
Because it's defined by other than
Hi,
For the win32.h, I really don't understand why _WINSOCKAPI_ was defined
before
winsock2.h
some google suggests that defining _WINSOCKAPI_ beforewindows.h prevents
inclusion of winsock.h but that does not have relation to inclusion of
winsock2.h and ifwinsock2.h is included first, it
Hi,
+/* __MINGW64_VERSION_MAJOR is related to both 32/64 bit gcc compiles by
+ * mingw-w64, however it gots defined only after
Why not use __MINGW32__, which is defined without including any headers?
Because it's defined by other than mingw-w64 compilers.
I see. That's because mingw (not
On 11/24/2011 06:29 AM, Lars Kanis wrote:
Isn't it better to check the value of macros itsef rather than checking for
system dependent macros that does not directly relate to the issue?
specifically for getaddrinfo.c case I think
#if EAI_NODATA != EAI_NONAME
is a better check than checking for
Hi PostgreSQL hackers,
support for Mingw-w64 compiler was added to postgres with commit 91812df.
Unfortunately only the 64 bit output is working right now. This issue was
already highlighted with initial patch in
http://archives.postgresql.org/pgsql-bugs/2011-07/msg00059.php
Mingw-w64 uses the
Hi,
Isn't it better to check the value of macros itsef rather than checking for
system dependent macros that does not directly relate to the issue?
specifically for getaddrinfo.c case I think
#if EAI_NODATA != EAI_NONAME
is a better check than checking for
#if !defined(__MINGW64_VERSION_MAJOR)
Hello, Lars.
You wrote:
LK Hi PostgreSQL hackers,
LK
LK support for Mingw-w64 compiler was added to postgres with commit
LK 91812df. Unfortunately only the 64 bit output is working right
LK now. This issue was already highlighted with initial patch in
LK
Hi,
2011-11-24 09:55 keltezéssel, Pavel Golub írta:
Can you please provide me with some howto on building PG sources with
mingw-w64?
Install Fedora 15 or 16, add this repo file into /etc/yum.repos.d :
http://build1.openftd.org/fedora-cross/fedora-cross.repo
Then yum install mingw*. This
Can you please provide me with some howto on building PG sources with
mingw-w64?
For 32/64 bit mingw-v4.6.1 on ubuntu 11.10:
apt-get install flex gcc-mingw-w64
./configure --host=i686-w64-mingw32 --build=x86_64-linux --without-zlib make
and
./configure --host=x86_64-w64-mingw32
Isn't it better to check the value of macros itsef rather than checking for
system dependent macros that does not directly relate to the issue?
specifically for getaddrinfo.c case I think
#if EAI_NODATA != EAI_NONAME
is a better check than checking for
#if !defined(__MINGW64_VERSION_MAJOR)
On 11/24/2011 04:39 AM, Lars Kanis wrote:
Can you please provide me with some howto on building PG sources with
mingw-w64?
For 32/64 bit mingw-v4.6.1 on ubuntu 11.10:
apt-get install flex gcc-mingw-w64
./configure --host=i686-w64-mingw32 --build=x86_64-linux
--without-zlib make
and
Hi,
The way to build natively with a mingw-w64 compiler is doumented fairly
simply at
http://www.postgresql.org/docs/current/static/installation-platform-notes.html#INSTALLATION-NOTES-MINGW:
To build 64 bit binaries using MinGW, install the 64 bit tool set
from
43 matches
Mail list logo
