Thread: Has anyone used CLANG yet?
This is a C front end for the LLVM compiler... I noticed that it entered Debian/Unstable today: http://packages.debian.org/sid/main/clang I thought it would be interesting to see if PostgreSQL compiles with this, as an alternative compiler that should presumably become more and more available on Linux et al. (And I suppose that the randomly selected .sig is supremely apropos!) configure blows up here at the following: conftest.c:75:28: error: invalid token after top level declarator extern unsigned int PASCAL accept (unsigned int, void *, void *); I suspect there's something about PASCAL that's a problem, as clang is nominally supposed to be a C compiler ;-). I haven't looked deeper, so haven't the remotest idea how deep the issue lies. At any rate, I should poke at this further soon, but if it seems interesting to others, well, CLANG is now an easy install on some number of systems! -- let name="cbbrowne" and tld="gmail.com" in name ^ "@" ^ tld;; http://linuxdatabases.info/info/postgresql.html "The problem with the cutting edge is that someone has to bleed." -- Zalman Stern
Chris Browne wrote: > I suspect there's something about PASCAL that's a problem, as clang is > nominally supposed to be a C compiler ;-). > "Pascal" refers to a way of different way of pushing things onto the stack when calling things; there's "Pascal order" and "c order" when you call a function, each approach has its good and bad sides. There's work in progress to support different calling conventions including Pascal order for LLVM at http://nondot.org/sabre/LLVMNotes/CustomCallingConventions.txt . At this point, supporting different call conventions is supported in LLVM 1.5: http://llvm.org/releases/1.5/docs/LangRef.html#callingconv but it doesn't look like the syntax to support the Pascal one has made it in there yet. Probably requires a fairly small patch to LLVM now that the main infrastructure is available. Don't know if it's feasible to rip all the Pascal convention code out PostgreSQL, that's the other approach. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.com
On Dec 9, 2009, at 4:23 PM, Chris Browne wrote: > This is a C front end for the LLVM compiler... I noticed that it > entered Debian/Unstable today: > > http://packages.debian.org/sid/main/clang > > I thought it would be interesting to see if PostgreSQL compiles with > this, as an alternative compiler that should presumably become more and > more available on Linux et al. (And I suppose that the randomly > selected .sig is supremely apropos!) > > configure blows up here at the following: > > conftest.c:75:28: error: invalid token after top level declarator > extern unsigned int PASCAL accept (unsigned int, void *, void *); > > I suspect there's something about PASCAL that's a problem, as clang is > nominally supposed to be a C compiler ;-). > > I haven't looked deeper, so haven't the remotest idea how deep the issue > lies. > > At any rate, I should poke at this further soon, but if it seems > interesting to others, well, CLANG is now an easy install on some number > of systems! Clang works for me on MacOS 10.6.2:/Developer/usr/bin/clang --version clang version 1.0.1 (http://llvm.org/svn/llvm-project/cfe/tags/Apple/clang-24 exported) Target: x86_64-apple-darwin10 CC="/Developer/usr/bin/clang" ./configure --prefix=/Users/agentm/pgsql841/ make -j 8 /Users/agentm/pgsql841/initdb -E UTF8 ../data ./pg_ctl -D ../data/ start server starting RD07:bin agentm$ LOG: database system was shut down at 2009-12-09 17:01:51 EST LOG: database system is ready to accept connections LOG: autovacuum launcher started /Users/agentm/pgsql841/psql postgres psql (8.4.1) Type "help" for help. postgres=# select 1;?column? ---------- 1 (1 row) I do see lots of warnings regarding unsupported compiler flags: clang: warning: argument unused during compilation: '-no-cpp-precomp' clang: warning: argument unused during compilation: '-O2' clang: warning: argument unused during compilation: '-Wall' clang: warning: argument unused during compilation: '-Wmissing-prototypes' clang: warning: argument unused during compilation: '-Wpointer-arith' clang: warning: argument unused during compilation: '-Wdeclaration-after-statement' clang: warning: argument unused during compilation: '-Wendif-labels' clang: warning: argument unused during compilation: '-fno-strict-aliasing' clang: warning: argument unused during compilation: '-fwrapv' and some code-based warnings: print.c:1105:24: warning: field width should have type 'int', but argument has type 'unsigned int' [-Wformat] fprintf(fout, "%-s%*s", hlineptr[line_count].ptr, ^ pl_exec.c:3529:6: warning: expression result unused [-Wunused-value] ItemPointerSetInvalid(&(tmptup.t_self)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../../../src/include/storage/itemptr.h:134:2: note: instantiated from: BlockIdSet(&((pointer)->ip_blkid), InvalidBlockNumber),\ ^ ../../../../src/include/storage/block.h:86:2: note: instantiated from: AssertMacro(PointerIsValid(blockId)), \ ^ ../../../../src/include/postgres.h:675:39: note: instantiated from: #define AssertMacro(condition) ((void)true) ^ ../../../../src/include/c.h:185:15: note: instantiated from: #define true ((bool) 1) You are probably running configure with gcc, no? FYI: with clang: time make (not -j 8) real 1m46.511s user 1m26.295s sys 0m14.639s with gcc: time make real 2m41.934s user 2m20.778s sys 0m17.441s du -h pgsql841gcc/bin/*52K pgsql841gcc/bin/clusterdb52K pgsql841gcc/bin/createdb60K pgsql841gcc/bin/createlang52K pgsql841gcc/bin/createuser52K pgsql841gcc/bin/dropdb60K pgsql841gcc/bin/droplang52K pgsql841gcc/bin/dropuser 616K pgsql841gcc/bin/ecpg72K pgsql841gcc/bin/initdb32K pgsql841gcc/bin/pg_config28K pgsql841gcc/bin/pg_controldata36K pgsql841gcc/bin/pg_ctl 280K pgsql841gcc/bin/pg_dump68K pgsql841gcc/bin/pg_dumpall36K pgsql841gcc/bin/pg_resetxlog 128K pgsql841gcc/bin/pg_restore 4.6M pgsql841gcc/bin/postgres 4.0K pgsql841gcc/bin/postmaster 340K pgsql841gcc/bin/psql52K pgsql841gcc/bin/reindexdb32K pgsql841gcc/bin/vacuumdb du -h pgsql841/bin/* (clang build)52K pgsql841/bin/clusterdb52K pgsql841/bin/createdb60K pgsql841/bin/createlang52K pgsql841/bin/createuser48K pgsql841/bin/dropdb60K pgsql841/bin/droplang48K pgsql841/bin/dropuser 612K pgsql841/bin/ecpg72K pgsql841/bin/initdb28K pgsql841/bin/pg_config28K pgsql841/bin/pg_controldata36K pgsql841/bin/pg_ctl 272K pgsql841/bin/pg_dump68K pgsql841/bin/pg_dumpall36K pgsql841/bin/pg_resetxlog 124K pgsql841/bin/pg_restore 4.5M pgsql841/bin/postgres 4.0K pgsql841/bin/postmaster 344K pgsql841/bin/psql52K pgsql841/bin/reindexdb32K pgsql841/bin/vacuumdb Cheers, M
agentm@themactionfaction.com ("A.M.") writes:
[Much of interest elided... Cool to see that clang clearly *can*
compile PostgreSQL...]
> You are probably running configure with gcc, no?
I was *attempting* to run configure using clang:
CC=/usr/bin/clang ./configure --prefix=/home/chris/dbs/postgresql-git-head
I know it's using clang, as some of the early tests indicate that
specifically.
checking types of arguments for accept()... configure: error: could not determine argument types
It's worth noting that the problem is NOT fundamentally any
Pascal-parm-passing-style issue; that's a red herring. The trouble is
that it's not finding a function signature for accept(), and a number of
the attempts (well, half of them...) happen to try to use Pascal
parm-passing conventions.
Actually, there's a little more mystery to it... I pulled out the C
code from config.log that corresponds with my favorite
/usr/include/sys/socket.h accept() signature, and clang is happy to
compile it, even though configure logs, in config.log, that there was a
mismatch. So, for some reason, configure had no problem running clang a
bunch of times against *other* C fragments, but somehow didn't like how
it ran this one.
Presumably there's some dang GNU magic going on ;-).
Thanks for verifying that the notion of compiling PostgreSQL using clang
is something that in principle ought to be able to work. Perhaps this
first Debian packaging of it has some deficiency, or my workstation
hates me! :-).
--
output = ("cbbrowne" "@" "gmail.com")
The real problem with the the year 2000 is that there are too many
zero bits and that adversely affects the global bit density.
-- Boyd Roberts <boyd@france3.fr>
On ons, 2009-12-09 at 16:23 -0500, Chris Browne wrote: > This is a C front end for the LLVM compiler... I noticed that it > entered Debian/Unstable today: > > http://packages.debian.org/sid/main/clang > > I thought it would be interesting to see if PostgreSQL compiles with > this, as an alternative compiler that should presumably become more and > more available on Linux et al. (And I suppose that the randomly > selected .sig is supremely apropos!) > > configure blows up here at the following: > > conftest.c:75:28: error: invalid token after top level declarator > extern unsigned int PASCAL accept (unsigned int, void *, void *); > > I suspect there's something about PASCAL that's a problem, as clang is > nominally supposed to be a C compiler ;-). > > I haven't looked deeper, so haven't the remotest idea how deep the issue > lies. The problem is the -D_GNU_SOURCE in src/template/linux. This bit from /usr/include/sys/socket.h would appear to be the explanation. Apparently CLANG claims to be GCC-something-recent but does not implement this transparent-union hocus pocus in quite the same way. If you don't use _GNU_SOURCE, then it uses the #define version and the configure test passes. /* This is the type we use for generic socket address arguments. With GCC 2.7 and later, the funky union causes redeclarations or uses with any of the listed types to be allowed withoutcomplaint. G++ 2.7 does not support transparent unions so there we want the old-style declaration, too. */ #if defined __cplusplus || !__GNUC_PREREQ (2, 7) || !defined __USE_GNU # define __SOCKADDR_ARG struct sockaddr *__restrict # define __CONST_SOCKADDR_ARG __const struct sockaddr * #else /* Add more `struct sockaddr_AF' types here as necessary. These are all the ones I found on NetBSD and Linux. */ # define __SOCKADDR_ALLTYPES \ __SOCKADDR_ONETYPE (sockaddr) \ __SOCKADDR_ONETYPE (sockaddr_at) \ __SOCKADDR_ONETYPE (sockaddr_ax25)\ __SOCKADDR_ONETYPE (sockaddr_dl) \ __SOCKADDR_ONETYPE (sockaddr_eon) \ __SOCKADDR_ONETYPE (sockaddr_in)\ __SOCKADDR_ONETYPE (sockaddr_in6) \ __SOCKADDR_ONETYPE (sockaddr_inarp) \ __SOCKADDR_ONETYPE (sockaddr_ipx)\ __SOCKADDR_ONETYPE (sockaddr_iso) \ __SOCKADDR_ONETYPE (sockaddr_ns) \ __SOCKADDR_ONETYPE (sockaddr_un) \__SOCKADDR_ONETYPE (sockaddr_x25) # define __SOCKADDR_ONETYPE(type) struct type *__restrict __##type##__; typedef union { __SOCKADDR_ALLTYPES } __SOCKADDR_ARG __attribute__ ((__transparent_union__)); # undef __SOCKADDR_ONETYPE # define __SOCKADDR_ONETYPE(type) __const struct type *__restrict __##type##__; typedef union { __SOCKADDR_ALLTYPES } __CONST_SOCKADDR_ARG __attribute__ ((__transparent_union__)); # undef __SOCKADDR_ONETYPE #endif Unfortunately, removing _GNU_SOURCE currently breaks the build because it masks the definition of struct ucred from the headers. That could be fixed with more autoconfigury. And it breaks PL/Perl, as the note there says.