Thread: LLVM / clang
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 ;)
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 shouldI 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 actuallyuses 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
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.
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.
Peter Eisentraut <peter_e@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
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.
Peter Eisentraut <peter_e@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
Peter Eisentraut <peter_e@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
backendslots doesn't need to be
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
On tor, 2010-06-10 at 09:52 -0400, Tom Lane wrote: > Peter Eisentraut <peter_e@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.
Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp> writes:
> Peter Eisentraut <peter_e@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
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.
Attachment
On Fri, 25 Jun 2010 15:49:40 -0400, Peter Eisentraut <peter_e@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?
On ons, 2010-06-30 at 20:10 +0200, Gibheer wrote: > On Fri, 25 Jun 2010 15:49:40 -0400, Peter Eisentraut <peter_e@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.
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?
Peter Eisentraut <peter_e@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
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