[HACKERS] LLVM / CLang / PostgreSQL

2013-01-11 Thread Joshua D. Drake


Hello,

Has anyone played with this? Seen any results? It looks like most 
testing is being done on Mac OSX (via buildfarm).


JD
--
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / CLang / PostgreSQL

2013-01-11 Thread Peter Eisentraut
On 1/11/13 4:03 PM, Joshua D. Drake wrote:
 Has anyone played with this? Seen any results? It looks like most
 testing is being done on Mac OSX (via buildfarm).

Works fine.  We also have non-OSX tests on the buildfarm for it.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-07-10 Thread Peter Eisentraut
On fre, 2010-06-11 at 07:00 +0300, Peter Eisentraut wrote:
 The second problem is that the prototype check for accept() fails.
 This
 is because glibc defines the second argument to be a transparent
 union, apparently to make it look like a lot of things at once.
 clang
 apparently doesn't understand that.  One could address this by
 checking
 for the typedef that glibc uses explicitly in the configure check, but
 that would appear to defeat the point of the *transparent* union.  A
 workaround is to remove -D_GNU_SOURCE from src/template/linux.

For the record, there is already a bug report about this:
http://llvm.org/bugs/show_bug.cgi?id=5365


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-07-08 Thread Peter Eisentraut
On fre, 2010-06-25 at 15:49 -0400, Peter Eisentraut wrote:
 For the record, here is a patch that would address these issues.
 
 At the moment, I'm waiting to get my hands on the new version 2.7 of
 clang to see if some of these issues have gone away.
 
 Considering that clang already helped us find one bug in the code, I
 think it's worth trying to make this work.

So, clang 2.7 didn't fix it.  Do we want to proceed with my patch or
leave clang unsupported?


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-07-08 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes:
 So, clang 2.7 didn't fix it.  Do we want to proceed with my patch or
 leave clang unsupported?

Given that the patch breaks plperl, I'd vote no ... but in any case
right now is not the time to be applying it.  Maybe it would be useful
to put it in HEAD after we branch 9.0.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-06-30 Thread Gibheer
On Fri, 25 Jun 2010 15:49:40 -0400, Peter Eisentraut pete...@gmx.net
wrote:
 
 For the record, here is a patch that would address these issues.
 
 At the moment, I'm waiting to get my hands on the new version 2.7 of
 clang to see if some of these issues have gone away.
 
 Considering that clang already helped us find one bug in the code, I
 think it's worth trying to make this work.

I tried your patch, but it is only working, when I set CLANG=yes. As
I'm not really an expert in makefiles, my first thought was, that it
should work, when I set CC=clang or is it not possible to detect,
which compiler is used?

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-06-30 Thread Peter Eisentraut
On ons, 2010-06-30 at 20:10 +0200, Gibheer wrote:
 On Fri, 25 Jun 2010 15:49:40 -0400, Peter Eisentraut pete...@gmx.net
 wrote:
  
  For the record, here is a patch that would address these issues.
  
  At the moment, I'm waiting to get my hands on the new version 2.7 of
  clang to see if some of these issues have gone away.
  
  Considering that clang already helped us find one bug in the code, I
  think it's worth trying to make this work.
 
 I tried your patch, but it is only working, when I set CLANG=yes. As
 I'm not really an expert in makefiles, my first thought was, that it
 should work, when I set CC=clang or is it not possible to detect,
 which compiler is used?

I suspect you didn't run autoreconf.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-06-25 Thread Peter Eisentraut
On fre, 2010-06-11 at 07:00 +0300, Peter Eisentraut wrote:
 The second problem is that the prototype check for accept() fails.
 This
 is because glibc defines the second argument to be a transparent
 union, apparently to make it look like a lot of things at once.
 clang
 apparently doesn't understand that.  One could address this by
 checking
 for the typedef that glibc uses explicitly in the configure check, but
 that would appear to defeat the point of the *transparent* union.  A
 workaround is to remove -D_GNU_SOURCE from src/template/linux.
 
 Predictably, this will make PL/Perl fail to build.
 
 Also, it will make src/backend/libpq/auth.c fail to build, because
 struct ucred is only defined when _GNU_SOURCE is used.  This would
 actually fail to work on GCC as well, so I think we should add an
 explicit configure check for struct ucred. 

For the record, here is a patch that would address these issues.

At the moment, I'm waiting to get my hands on the new version 2.7 of
clang to see if some of these issues have gone away.

Considering that clang already helped us find one bug in the code, I
think it's worth trying to make this work.
diff --git a/configure.in b/configure.in
index 0a529fa..bb1d0dd 100644
--- a/configure.in
+++ b/configure.in
@@ -390,6 +390,11 @@ choke me
 
 AC_SUBST(SUN_STUDIO_CC)
 
+# Check if it's Clang, which defines __clang__.
+AC_TRY_COMPILE([], [...@%:@ifndef __clang__
+choke me
+...@%:@endif], [CLANG=yes], [CLANG=no])
+
 unset CFLAGS
 
 #
@@ -1102,7 +1107,7 @@ AC_TYPE_INTPTR_T
 AC_TYPE_UINTPTR_T
 AC_TYPE_LONG_LONG_INT
 
-AC_CHECK_TYPES([struct cmsgcred, struct fcred, struct sockcred], [], [],
+AC_CHECK_TYPES([struct ucred,struct cmsgcred, struct fcred, struct sockcred], [], [],
 [#include sys/param.h
 #include sys/types.h
 #include sys/socket.h
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index b06b391..27482bd 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -1786,7 +1786,7 @@ ident_unix(int sock, char *ident_user)
 	strlcpy(ident_user, pass-pw_name, IDENT_USERNAME_MAX + 1);
 
 	return true;
-#elif defined(SO_PEERCRED)
+#elif defined(SO_PEERCRED)  defined(HAVE_STRUCT_UCRED)
 	/* Linux style: use getsockopt(SO_PEERCRED) */
 	struct ucred peercred;
 	ACCEPT_TYPE_ARG3 so_len = sizeof(peercred);
diff --git a/src/include/pg_config.h.in b/src/include/pg_config.h.in
index fd169b6..8d41549 100644
--- a/src/include/pg_config.h.in
+++ b/src/include/pg_config.h.in
@@ -529,6 +529,9 @@
 /* Define to 1 if `tm_zone' is member of `struct tm'. */
 #undef HAVE_STRUCT_TM_TM_ZONE
 
+/* Define to 1 if the system has the type `struct ucred'. */
+#undef HAVE_STRUCT_UCRED
+
 /* Define to 1 if you have the SupportDefs.h header file. */
 #undef HAVE_SUPPORTDEFS_H
 
diff --git a/src/template/linux b/src/template/linux
index 68da3bb..aff39e8 100644
--- a/src/template/linux
+++ b/src/template/linux
@@ -1,7 +1,9 @@
 # $PostgreSQL$
 
 # Force _GNU_SOURCE on; plperl is broken with Perl 5.8.0 otherwise
-CPPFLAGS=$CPPFLAGS -D_GNU_SOURCE
+if test $CLANG != yes; then
+  CPPFLAGS=$CPPFLAGS -D_GNU_SOURCE
+fi
 
 # If --enable-profiling is specified, we need -DLINUX_PROFILE
 PLATFORM_PROFILE_FLAGS=-DLINUX_PROFILE

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-06-11 Thread Peter Eisentraut
On tor, 2010-06-10 at 09:52 -0400, Tom Lane wrote:
 Peter Eisentraut pete...@gmx.net writes:
  Quick testing shows that clang doesn't get through the configure stage
  on this Debian system -- it looks like some amount of better integration
  with glibc might be needed.  Building with llvm-gcc works fine, but I
  understand that using llvm-gcc with native code generation isn't all
  that different from using gcc itself, so that's not a surprising result.
  The only issue is that the float8 regression test fails, so it is
  apparently not *exactly* the same.
 
 There's a buildfarm animal using llvm-gcc, and it passes just fine ...
 so the float8 failure sounds to me like another integration problem.

The diff in this case is

*** src/test/regress/expected/float8.out
--- src/test/regress/results/float8.out
***
*** 384,390 
  SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
  ERROR:  value out of range: overflow
  SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
! ERROR:  value out of range: overflow
  SELECT 0 ^ 0 + 0 ^ 1 + 0 ^ 0.0 + 0 ^ 0.5;
   ?column? 
  --
--- 384,398 
  SELECT '' AS bad, f.f1 * '1e200' from FLOAT8_TBL f;
  ERROR:  value out of range: overflow
  SELECT '' AS bad, f.f1 ^ '1e200' from FLOAT8_TBL f;
!  bad | ?column? 
! -+--
!  |0
!  |  NaN
!  |  NaN
!  |  NaN
!  |  NaN
! (5 rows)
! 
  SELECT 0 ^ 0 + 0 ^ 1 + 0 ^ 0.0 + 0 ^ 0.5;
   ?column? 
  --

which means that this combo signals an overflow in pow() by returning
NaN and not setting errno.

Curiously enough, the problem goes away when you insert elog()
statements after the pow() call.  Could be a code generation/pipelining
issue.

Btw., this is

llvm-gcc (GCC) 4.2.1 (Based on Apple Inc. build 5649) (LLVM build)

which sounds somewhat old.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-06-11 Thread Tom Lane
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
 Peter Eisentraut pete...@gmx.net wrote:
 max_locks_per_xact != max_locks_per_xact)
 
 Looks like a bug.

 Ah, it should be compared with the same name field in ControlFile.

Yeah, obvious typo, please commit.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-06-10 Thread Peter Eisentraut
On ons, 2010-06-09 at 09:59 +0200, Florian Pflug wrote:
 The most heavily platform dependent part of the code is the spinlock
 implementation. You might want to check that it actually uses the
 version optimized for your platform, not the (much slower) generic
 implementation based on semaphores.

You only get the slow implementation if you configure explicitly with
--disable-spinlocks.  A toolchain that didn't support spinlocks would
fail the build and then the user could use that option to get past that
problem.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-06-10 Thread Peter Eisentraut
On tis, 2010-06-08 at 12:12 +0200, P. Caillaud wrote:
 I'd like to experiment on compiling postgres with LLVM (either llvm-gcc or  
 clang) on Linux, is it supported ? Where should I start ?

The way to choose a compiler is

./configure CC=your-cc ...other...options...

We support a fair amount of non-GCC compilers, so supporting one or two
more should be possible.

Quick testing shows that clang doesn't get through the configure stage
on this Debian system -- it looks like some amount of better integration
with glibc might be needed.  Building with llvm-gcc works fine, but I
understand that using llvm-gcc with native code generation isn't all
that different from using gcc itself, so that's not a surprising result.
The only issue is that the float8 regression test fails, so it is
apparently not *exactly* the same.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-06-10 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes:
 Quick testing shows that clang doesn't get through the configure stage
 on this Debian system -- it looks like some amount of better integration
 with glibc might be needed.  Building with llvm-gcc works fine, but I
 understand that using llvm-gcc with native code generation isn't all
 that different from using gcc itself, so that's not a surprising result.
 The only issue is that the float8 regression test fails, so it is
 apparently not *exactly* the same.

There's a buildfarm animal using llvm-gcc, and it passes just fine ...
so the float8 failure sounds to me like another integration problem.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-06-10 Thread Peter Eisentraut
On tor, 2010-06-10 at 11:55 +0300, Peter Eisentraut wrote:
 Quick testing shows that clang doesn't get through the configure stage
 on this Debian system -- it looks like some amount of better
 integration with glibc might be needed.

Some details on this ...

configure has two problems.  The first is a present but cannot be
compiled warning about wctype.h.  This is described here:
http://llvm.org/bugs/show_bug.cgi?id=6691.  It looks like glibc 2.11
or some later version will fix this.  (eglibc 2.11 doesn't have the fix
yet.)  But this doesn't cause a problem during the compile.

The second problem is that the prototype check for accept() fails.  This
is because glibc defines the second argument to be a transparent
union, apparently to make it look like a lot of things at once.  clang
apparently doesn't understand that.  One could address this by checking
for the typedef that glibc uses explicitly in the configure check, but
that would appear to defeat the point of the *transparent* union.  A
workaround is to remove -D_GNU_SOURCE from src/template/linux.

Predictably, this will make PL/Perl fail to build.

Also, it will make src/backend/libpq/auth.c fail to build, because
struct ucred is only defined when _GNU_SOURCE is used.  This would
actually fail to work on GCC as well, so I think we should add an
explicit configure check for struct ucred.

The rest of the build goes through and the regression tests pass.

Some new warnings, however:

xlog.c:7759:22: warning: self-comparison always results in a constant
value
max_locks_per_xact != max_locks_per_xact)
   ^

Looks like a bug.

postmaster.c:3386:18: warning: more data arguments than '%' conversions
[-Wformat-extra-args]
 remote_host, remote_port);
  ^

dt_common.c:818:75: warning: more data arguments than '%' conversions
[-Wformat-extra-args]
sprintf(str + strlen(str), (min != 0) ?
%+03d:%02d : %+03d, hour, min);

~~~^

[and a few more like that]

These are instances where a format string is an expression that results
in a variable number of format arguments.  Not sure if that is actually
legal in C.

print.c:778:22: warning: field width should have type 'int', but
argument has type 'unsigned int' [-Wformat]
fprintf(fout, %-*s%s\n, (width_total -
width) / 2, ,
 ^
~

[and a few more like that]

Not sure about that.

Also there are boatloads of warnings in the regex stuff about unused
things, that we probably don't have to worry about.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-06-10 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes:
 [ assorted LLVM warnings ]

 dt_common.c:818:75: warning: more data arguments than '%' conversions
 [-Wformat-extra-args]
 sprintf(str + strlen(str), (min != 0) ?
 %+03d:%02d : %+03d, hour, min);
 ~~~^

 [and a few more like that]

 These are instances where a format string is an expression that results
 in a variable number of format arguments.  Not sure if that is actually
 legal in C.

I believe it's legal, but I'd be in favor of making a project policy
against it, simply because you aren't going to get any static checking
from gcc about whether the arguments match the format string.  There
isn't any good excuse not to code the above like

if (min != 0)
sprintf(str + strlen(str), %+03d:%02d, hour, min);
else
sprintf(str + strlen(str), %+03d, hour);

which would produce warnings if you managed to mess up the format match.

 print.c:778:22: warning: field width should have type 'int', but
 argument has type 'unsigned int' [-Wformat]
 fprintf(fout, %-*s%s\n, (width_total -
 width) / 2, ,

 Not sure about that.

That one, on the other hand, is pretty silly ...

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-06-10 Thread Takahiro Itagaki

Peter Eisentraut pete...@gmx.net wrote:

 Some new warnings, however:
 
 xlog.c:7759:22: warning: self-comparison always results in a constant
 value
 max_locks_per_xact != max_locks_per_xact)
^
 
 Looks like a bug.

Ah, it should be compared with the same name field in ControlFile.

Index: src/backend/access/transam/xlog.c
===
--- src/backend/access/transam/xlog.c   (HEAD)
+++ src/backend/access/transam/xlog.c   (fixed)
@@ -7756,7 +7756,7 @@
if (wal_level != ControlFile-wal_level ||
MaxConnections != ControlFile-MaxConnections ||
max_prepared_xacts != ControlFile-max_prepared_xacts ||
-   max_locks_per_xact != max_locks_per_xact)
+   max_locks_per_xact != ControlFile-max_locks_per_xact)
{
/*
 * The change in number of backend slots doesn't need to be



Regards,
---
Takahiro Itagaki
NTT Open Source Software Center



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] LLVM / clang

2010-06-09 Thread Florian Pflug
On Jun 8, 2010, at 12:12 , P. Caillaud wrote:
 I'd like to experiment on compiling postgres with LLVM (either llvm-gcc or 
 clang) on Linux, is it supported ? Where should I start ?

Setting the environment variables CC and perhabs LD to your favorite compile 
before running ./configure should do the trick. If the compilation succeeds, 
should should probably try to run the regression tests with make check.

The most heavily platform dependent part of the code is the spinlock 
implementation. You might want to check that it actually uses the version 
optimized for your platform, not the (much slower) generic implementation based 
on semaphores.

BTW, last time I tried compiling with clang basically worked on OSX, despite 
triggering a helluva lot of warnings.

best regards,
Florian Pflug



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] LLVM / clang

2010-06-08 Thread P. Caillaud

Hello,

I'd like to experiment on compiling postgres with LLVM (either llvm-gcc or  
clang) on Linux, is it supported ? Where should I start ?


Thanks ;)


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers