Has anyone used CLANG yet?

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/clusterdb
52K pgsql841gcc/bin/createdb
60K pgsql841gcc/bin/createlang
52K pgsql841gcc/bin/createuser
52K pgsql841gcc/bin/dropdb
60K pgsql841gcc/bin/droplang
52K pgsql841gcc/bin/dropuser
616K pgsql841gcc/bin/ecpg
72K pgsql841gcc/bin/initdb
32K pgsql841gcc/bin/pg_config
28K pgsql841gcc/bin/pg_controldata
36K pgsql841gcc/bin/pg_ctl
280K pgsql841gcc/bin/pg_dump
68K pgsql841gcc/bin/pg_dumpall
36K pgsql841gcc/bin/pg_resetxlog
128K pgsql841gcc/bin/pg_restore
4.6M pgsql841gcc/bin/postgres
4.0K pgsql841gcc/bin/postmaster
340K pgsql841gcc/bin/psql
52K pgsql841gcc/bin/reindexdb
32K pgsql841gcc/bin/vacuumdb

du -h pgsql841/bin/* (clang build)
52K pgsql841/bin/clusterdb
52K pgsql841/bin/createdb
60K pgsql841/bin/createlang
52K pgsql841/bin/createuser
48K pgsql841/bin/dropdb
60K pgsql841/bin/droplang
48K pgsql841/bin/dropuser
612K pgsql841/bin/ecpg
72K pgsql841/bin/initdb
28K pgsql841/bin/pg_config
28K pgsql841/bin/pg_controldata
36K pgsql841/bin/pg_ctl
272K pgsql841/bin/pg_dump
68K pgsql841/bin/pg_dumpall
36K pgsql841/bin/pg_resetxlog
124K pgsql841/bin/pg_restore
4.5M pgsql841/bin/postgres
4.0K pgsql841/bin/postmaster
344K pgsql841/bin/psql
52K pgsql841/bin/reindexdb
32K 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 without complaint.
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.